eyt*

Find your next scenic drive in the Pacific Northwest

February 11, 2007

C++ Strongly-Typed Enumerations...

With the release on Java 5, we finally have enumerations in Java, but they really outdone themselves, in that an enumerated type is actually a class, where you can add your own methods. Take, for example, this code:

  1. public enum Color {
  2.   Red,
  3.   Yellow,
  4.   Orange,
  5.   Green,
  6.   Blue,
  7.   Brown,
  8.   Black,
  9.   Purple;
  10.  
  11.   public boolean isPrimaryColor() {
  12.     switch ( this ) {
  13.     case Red:
  14.     case Blue:
  15.     case Yellow:
  16.       return true;
  17.  
  18.     default:
  19.       return false;
  20.     }
  21.   }
  22. }

Instead of having a utility class off to the side that takes an enumeration as a parameter, you can now add that method directly to the enumeration, and I do not think that there would be much controversy that color.isPrimaryColor(); reads better than ColorUtils.isPrimaryColor( color );.

Putting this aside for a moment, C++09 is cleaning up their enumerations by adding support for strongly type enums (PDF Proposal).

In the current version of C++, we have problems with code like this:

  1. enum Color { RED, YELLOW, ORANGE, GREEN, BLUE, BROWN, BLACK, PURPLE };
  2. enum TerrorAlertLevel { RED, ORANGE, YELLOW, BLUE, GREEN };

This does not compile, because by the time it gets to TerrorAlertLevel, RED, ORANGE, YELLOW, BLUE, and GREEN are already defined, thanks to the Color enumeration. And worst off, if you have a coding standard that does not require you to have your enumerations all in caps (which makes sense, since part of the reason that Macros are usually done in caps is to discourage their use), then you could have an issue with any variables, such as int red = 0xFF0000; would not compile if the enumeration was all in lower-case.

As such, developers in C++ tend to add a prefix to the definition, such as:

  1. enum Color { COLOR_RED, COLOR_YELLOW, COLOR_ORANGE, COLOR_GREEN, COLOR_BLUE, COLOR_BROWN, COLOR_BLACK, COLOR_PURPLE };
  2. enum TerrorAlertLevel { TAL_RED, TAL_ORANGE, TAL_YELLOW, TAL_BLUE, TAL_GREEN };

Oh, that looks friendly.

Well, to help in that friendliness, C++09 is adding strongly typed enums. This is done by adding the class keyword to the enum definition. For example, the first C++ example above could compile under C++09 as this:

  1. enum class Color { RED, YELLOW, ORANGE, GREEN, BLUE, BROWN, BLACK, PURPLE };
  2. enum class TerrorAlertLevel { RED, ORANGE, YELLOW, BLUE, GREEN };

The bold emphasizes the difference.

Conceptually, I think this is a great addition to C++, making it easier to reuse enumerations and avoiding the crazy compilation errors that you can get if you accidentally name your variable a name that has already been defined in an enum.

The part that I do not like about this proposal, however, is the fact that it uses the keyword class but it is not a class. You cannot add member functions to it, which because of the power of the Java enumerations, I think this is confusing for developers which experience with Java enumerations.

C# enumerations are strongly typed but you cannot add any methods to them. But at least, they do not use the word class in their definition.

While I more than welcome the strongly-typed nature of enumerations in C++, I think that the implementation could have overloaded a better keyword than class. Since it does seem like this has been accepted already, hopefully a future version of the standard will add the ability to add member functions to the enumeration, minimizing some of this confusion.

November 24, 2006

A feed for mFiles.co.uk...

One of the music sites that I've enjoyed over the years has been mFiles. Not only does it provide you with great commentary ranging from classical composers to modern pieces, but it also provides you with pieces of music in MIDI, MP3, and, my personal favorite, free sheet music. I have found it to be a great place to get introduced to various musical styles and composers.

One thing that I noticed a while ago was that this site did not have a feed, so to keep up with the site's regular updates, one had to visit the site regularly.

After approaching Jim Paterson (the site's webmaster) about an RSS feed, I decided to write a little program that will generate an RSS feed from mFiles. The feed is now available at http://www.eyt.ca/mfiles.co.uk.rss (which is linked to directly from mFiles.co.uk's homepage).

My program is very simple, and usually visits mFiles once a day, parses through the articles, and generates an RSS 2.0 feed. The feed currently only contains the titles of the articles and a link to mFiles.co.uk. A few notes about the feed:

If you have any suggestions, problems, or questions about the feed, please feel free to contact me, or if you have questions about mFiles, please contact mFiles directly.

I hope that you will find this useful!

November 23, 2006

Error Changing Samba Password...

When I went to change my Samba password earlier today, I got this error message:

eyt@zaterdag 19% smbpasswd
Old SMB password:
New SMB password:
Retype new SMB password:
Error connecting to 127.0.0.1 (Connection refused)
unable to connect to SMB server on machine 127.0.0.1. Error was : SUCCESS - 0.
Failed to change password for eyt

Googling did not say it directly, but it appears that the problem above was that my smb.conf did not mention 127.0.0.1 (localhost) for the listening interfaces; adding 127.0.0.1 to the interfaces setting in the global section resolved my problem, as demonstrated here:

[global]
...
interfaces = 127.0.0.1 192.168.1.1/255.255.255.0
...

After this quick change and restarting Samba, I was able to change my password and all was happy again.

August 3, 2006

Corrupted Comments Table...

I was recently cleaning up the endless comment spam this blog gets, and at some point while doing this, I noticed that one comment ended up not being deletable. From the bBlog admin interface, it was not evident that there was a problem, and I decided to look at it when I got home. When I got home, I had received a couple more comment spams, but I could not delete these or the previous one from the admin interface, and so I decided to drop to the mysql interface.

The mysql interface seemed fine at first, as it allowed me to select * from bB_comments, however, when I attempted to delete all the items on hold, I noticed something different:

Some of my initial search results were non-conclusive as to what the deal was, and so I hoped that by restarting MySQL, that the error would be more evident. MySQL started up fine, but my query results now were different:

From that error message, I landed on this message that indicated that the repair was as simple as running the REPAIR query, as described here:

And now I am back in business and able to delete my comment spam. It is unclear what corrupted the table to begin with; I was impatient in deleting the comment spam, but I doubt that is the root cause. If it happens again, I will take a look.

August 2, 2006

Searching for nil in all the wrong places...

A few days ago, I was adding some migrations to a Ruby on Rails project, but when I went to initialize a newly created database, I saw this error:

This being the third or so time working in Ruby, I immediately thought that it was something I did, so I started up the automatically generated scripts/application, pasted my new code into there, and proceeded to use it. The code had a couple issues that I fixed and I was confident enough to try again.

But again, I got the same error message. I then decided to add a couple prints around the new code, and re-run it, but the error above occurred without my print outs. Not sure how to proceed, I asked for some assistance from some co-workers. The advice was great, and I learned a lot about Ruby and Rails, but it still did not resolve my problem.

Finally someone recommended adding --trace to the my command:

So that is very interesting. Note how there is nothing in the above points to anything of mine. In pondering this with one of my coworkers, I explained how one of the things that I tried during debugging it was renaming the name of the class and filename, and that struck a cord.

It turns out that the mess above was all caused by my filename. I had named my file revision_add_blah_to_myApp and named my class AddBlahToMyApp. The problem with this is that the Rails convention for class names requires me to either name my file revision_add_blah_to_my_app or name my class AddBlahToMyapp. This very subtle issue caused this most unusable error message to cause a few completely wasted hours.

I have blogged before about great and not so great exceptions and their handling. I think this also falls in that category of not-so-great. It would have been nice to know that this problem originated with an attempt to load a class that did not exist, for example. In that case, I would have looked at that issue more closer than looking for references to first (and indirect references thereof) where the object invoking that method could have been nil.

Earlier Entries

<  1  2  3  4  5  6  7  >

Navigation

Recent Posts

Get Firefox
eyt*