C++ Retro

For the last few months at work I have been working on PocketPC development in C++. It’s funny to go back to a language I once knew so well and get back into its groove. It has helped to heighten my appreciation of Java, while also showing me some things I like about C++ that Java does not have.

Firstly, the separation of the interface and implementation of C++ classes (into .h and .cpp files) probably sounds like good practice but it’s just a pain. To have to deal with your class split over two files especially if some of the code is inlined in the header is tedious. Java’s all-in-one approach is much easier for me.

Having to know who owns allocated memory is blah. If I receive a buffer from a caller, am I expected to free it or will the caller? Are we in sync? Double frees and memory leaks are often difficult to track down. I resurrected my reference-counting templates to remove some of this headache. I also have to interact with a VB UI in this project and I’d not done a lot of that before so I’m still worried about all those BSTRs.

Templates are cool, when they work. Of course, getting templates to instantiate is always something of a black art. Either they are not instantiated at all or you get multiple symbols. I usually end up inlining most things in my template classes.

I love operator overloading. I never abuse it – really. I like to be able to have dynamic structures look like arrays.

Resource Acquisition is Initialization (RAII). This technique is great for things like associating critical sections with code blocks and not having to remember to cover all exit paths, etc. Sort of like a Java synchronized block. In C++ you are always thinking about allocation and management of everything you do. In Java, you don’t worry about this mostly. That ease of use can, however, lull you into to not properly managing non-memory resources such as JDBC connections.

The Microsoft IDE for embedded development makes some of these things easier but it has some annoying failings. Many times my classes just disappear from the class view. I don’t know what triggers this. When this happens lots of the automated wizardy things stop working. Adding a method to an interface under these conditions will not get a stub implementation added to the class providing the interface.

The most grevious problem, however, is that sometimes the IDE grinds to a halt whenever a line is added or removed in the current buffer. I used the SysInternals tools to try and understand what is going on. During these editor pauses the IDE is checking whether a disk is still mounted thousands of times. I’m guessing this is something in my environment but it has affected different machines (laptops, desktops, etc). I have had to resort to an external editor.

The PocketPC emulator sometimes actually starts up. When it’s runnign it seems to pop-up at the most inconvenient times.

I see from Simon Fell’s Blog that there may be an IDE update. I’ll have to check it out.

Anyway it’s good to look again at how different languages do things. It’s relaxing to come back to Java but perhaps the refreshed awareness of all those allocations will make me more careful about object creation in Java.

One Reply to “C++ Retro”

  1. Really nice blogging!
    A question about the last paragraph arrised in my job today: Is it true that if a Thread object is created, and not start()ed, then it will never be garbage collected, even when out of scope? Otherwise what may cause this?

Comments are closed.