During my senior year I took on an ECE491 Independent Project course to follow up on a ECE476 Microcontrollers project. On the completion of ECE491 we had created a Low Speed USB 2.0 stack library for the Atmel Mega32 Microcontroller using ~$6 worth of hardware and ~6000 standard lines of C.

Everybody in ECE476 used the CodeVisionAVR IDE, but we were a unique group in using avr-gcc. Though most students were okay with it, there were some minor features missing from the CodeVision compiler at the time, such as the ability to allocate objects on the heap. ;)

We rewrote the ECE476 code base in ECE491, again using avr-gcc, because we realized that the USB protocol was a lot more complex than the stack we had originally written. One of my main gripes in ECE491 was that I was writing highly object oriented code in a language which didn’t support any of the syntax. I’m starting to hack on the code base again, and a port to C++ seems like a good idea (since avr-g++ is also available), but there are some significant trade-offs running through my mind.

The Trade-offs

Things I want from C++ in the project:

• Namespaces — I hate worrying about global namespace issues. Though I’m not a huge fan of C++’s namespacing implementation, I’ll sure take it over no namespaces. :)
• Templates — Casting to and from void *s in “containers” and haphazardly faking (efficient) tuples with void **s is extremely dangerous and causes really annoying bugs.
• Class syntax — It’s ugly faking object orientation in C. Supported syntax is important to me because writing object oriented code in C “requires” you to prefix every function with a class name, like so:

  void data_packet_recalculate_crc16(data_packet_t self) { ... }

  Plus, cool tools like doxygen don’t pick up on the fact you’re writing in an object oriented style and adjust output accordingly (not that I’d expect them to).

• Exceptions — If you’ve ever written a large amount of C code, you learn how precious basic exceptions are. gotos and cleanup code tend to get old after a short period of time.
• Default arguments — I’m a fan of default arguments since it cuts down on the number of wrapper functions you have to write and maintain (though keyword arguments are even cooler :).

Things I don’t want from C++ in the project:

• Larger binaries — The Atmel ATMega32 has 32KB of memory to fit my entire software stack, which I’ve found to be extremely confining, even with my C implementation (which manages reuse through void *s). The fact that templates cause the compiler to replicate code makes me worry.
• Don’t really care, but maybe worth mentioning: vtables — I want inheritance with vptrs because it makes maintenance significantly easier for the straightforward class hierarchies; however, 16MHz chips are slow. Damn slow. Having vtables for some of the most primitive data structures seems ominous; however, I’m pretty sure that performance is a lot lower on the totem pole than maintainability in this instance.

The First Google Hit Says…

I’ve read through Reducing C++ Code Bloat and found it thought provoking. Though the article writes about gcc 3.4 and I’m using gcc 4.2, I can’t imagine that the underlying code-bloat concepts have changed much. I’m betting a lot of the compiler directive advice is taken care of by gcc’s -Os, but I’ll make a note to check it out.

It seems sensible to give up on exceptions ahead of time, but there seems to be some hope that the compiler can figure out good code reuse for the templates. I’m compiling to ELF, then performing and objcopy to turn it into Intel Hex object format — I’m hoping that the conversion is trivial and the good ELF compilation referenced in the article will stick.

In the end it seems like I’m just gambling on how much template reuse will occur. I sure hope that if I do all the porting-to-C++ work it optimizes well — template hoisting looks like one of those idioms I’d prefer to leave alone. :(