Beware! The rules for when a destructor is called for a managed C++ class in Visual C++ are different than for “normal” C++ class.
Jochen Kalmbach recently posed a simple question about a managed C++ class; “Will the destructor be called in a managed class if the constructor has thrown an exception?”. The answer and the comments are illuminating and, to be honest, somewhat annoying.
In summary, yes, the destructor is called even if the constructor doesn’t complete, see here for more details.
ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class’s implicit interface. That is, given a class that does not inherit from an interface, it’s sometimes useful to be able to split the class into an implicit interface, the public operations that it provides, and treat that as if it were explicitly declared as an interface from which the class derives.
Am I a curmudgeon of technology? You betcha - Ted Neward over at “The Blog Ride” explains why he’s cynical about new technology and suggests that we’d do well to have a little more cynicism. I agree with him, I tend to take a similar position having been let down by various “silver bullets” in the past. I think I decided that it was my time spent working with OLE DB providers that caused me to be more cynical towards the Microsoft technology hype machine; When someone brings me a “cool” new technology and claims that because simple things are so easy to do in a sample my complex problem will also be easy to solve using the technology I ask to see the code that solves my problem…
In the fight to make C++ code easier to reason about and understand, never underestimate the value of a name. Giving something a decent name is the first step in thinking about the concept at a slightly more abstract level. Abstraction is all about selective forgetfulness, by grouping together several related program elements, defining a concept and giving that concept a name you can, from then on, choose to work at the level of the name rather than the detail.
VirtualKeyboard.jpg I recently purchased an iTech Bluetooth Virtual Keyboard for use with Michelle’s PDA. It’s basically a little box that’s about the size of two packets of chewing gum with a red window in the top. It projects a keyboard onto a flat surface and detects when you press the keys. It’s one of those devices that looks too cool to work, but it does, kinda… Unfortunately there were driver problems with the iPaq 4150 that meant that it would work for around 20 keypresses and then stop, reset itself, reconnect and then start working again… At first I thought that it was a problem with the keyboard but it worked fine with my laptop (though that’s hardly the point!
LEGO has announced a new version of their Mindstorms autonomous robot building system. I did a fair amount of playing around with the original Mindstorms kit way back when and created a system that allowed you to control your robots over a NetMeeting connection. The new Mindstorms NXT system sounds pretty cool. I like the idea of being able to use bluetooth to control and download programs to the robots and the new sensors sound much more complex than the old stuff.
Another extremely powerful tool that you can use to ensure that your C++ code communicates as clearly as possible is const. By correctly using const all the time when designing your abstractions you can divide an object’s interface into two smaller, easier to understand interfaces; one which does change the object’s internal state and one which doesn’t. By correctly using const all the time when defining constants and variables you can clearly communicate which are which.
When designing code it’s often easy to include undefined behaviour. The need for code that exhibits this kind of behaviour is, however, generally pretty rare and there are often ways around allowing undefined behaviour. In general it’s usually best to try to avoid undefined behaviour and instead be clear about exactly what happens under all usage conditions.
Undefined behaviour can be part of your contract with the client, you expect them to adhere to their side of the contract and if they do then you will keep your side; if they don’t then all bets are off.
One of my main aims when writing code in C++ is to have the code clearly communicate its purpose. I find it useful to be able to look at a single line in isolation and have a pretty good idea of what its effects are on the code that it cooperates with. Unfortunately C++ code can often be written in an imprecise way that makes reasoning about what it actually does harder than it needs to be.
There’s the first part of what I expect to be a very nice article about programming by contract in C++ over at The C++ Source: The Nuclear Reactor and the Deep Space Probe.
Updated 3rd Jan 2006 - the article now appears to be called Contract Programming 101.
