More notes on “Effective C++”

17 April, 2009 § 1 Comment

This is a continuation of a previous post that I started after I finished reading Effective C++ by Scott Meyers.

Item 6: Explicitly disallow the use of compiler-generated functions you do not want.
The recommended way of disallowing the use of compiler-generated functions is to privately declare the copy constructor and assignment operator without providing a definition of them. Omaha, aka Google Update, uses this pattern within their code base by using a macro called DISALLOW_EVIL_CONSTRUCTORS. The macro is called from private visibility.

Item 13: Use objects to manage resources.
Well written code that uses objects to manage resources should not have a single use of the operator delete. Classes like auto_ptr and boost::shared_ptr allow for single ownership of pointers and reference-counted pointers, respectively. Both of these classes will call delete on the contained pointer when it goes out of scope. This is perfect if you are worried about exceptional cases and want to make sure you don’t leak memory.

Item 18: Make interfaces easy to use correctly and hard to use incorrectly.
Enumerated types have an inherent problem associated with them. If you declare an enumerated type, you are not limiting your callers to use only the values within the enumerated type. Take a look at the code sample below:

enum eDayOfWeek { Sunday = 1, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday };
void PrintDayOfWeek( eDayOfWeek eDay );
... //function defintion elided
PrintDayOfWeek( (eDayOfWeek) 75 ); //unexpected behavior here

The way that Meyers handles this is by privately declaring the constructor and publicly declaring static methods that return objects, thus protecting against invalid uses of enumerated types. How does this look:

void PrintDayOfWeek( Day day );
... //function definition elided
PrintDayOfWeek( Day::Monday() );

Omaha aka Google Update

15 April, 2009 § Leave a comment

I just set up my environment and built Omaha, the open-source codename for Google Update. Google Update is used within Google Chrome and Google Earth.

Omaha’s functionality allows us to automatically update software without interrupting or distracting the user, which makes for a better user experience. Omaha checks for updates in the background, when it won’t interfere with the user, even if an application isn’t running. Doing so means that we avoid using a computer’s resources when it first starts, avoiding a common bottleneck in computer performance experience. Omaha does not perform updates when an application launches, because we understand people want to use the software when starting it up, not perform maintenance tasks first.

This is very cool technology. It would be nice if I opened up Firefox and instead of it telling me to run through a installer when there is a new version, I was just running the latest. Currently, the server that this software talks to can only be a Google server. I’m interested to see if there is a way to have it talk to third-party servers, or get your application registered with Google’s server.

An interesting use-case to want it to talk to a third-party server would be for enterprise software that has a client-server relationship. Let’s say you install a server on your network and users download a client from that server to use the software. Currently, there is a lot of work for that administrator when it comes time to update the server as they would have to update all the client machines (whether that means updating an image file or physically walking to all the machines).

How nice would it be for that administrator to update their one server and then have all the clients automatically updated! This would have to talk to the local server on the network, since it is up to the admin to update their server when they see the most stable time.

Any other ideas/uses?

Where Am I?

You are currently browsing entries tagged with omaha at JAWS.