next up previous
Next: Epilogue Up: Embedded Programming with C++ Previous: JavaAnyone?

Conclusions

uCR as a whole has become a richer environment, now that it works with more substantial processor boards. However, its original design goal to stay small and efficient seems to be working. The core library of uCR is still quite simple. We have also come to some conclusions on the matter of C++ and embedded programming.

We to this day face people telling us that C++ generates inefficient code that cannot possibly be practical for embedded systems where speed matters. The criticism that C++ leads to bad executable code is ridiculous, but at the same time accurate. Poor style or habits can in fact lead to awful results. On the other hand, a skilled C++ programmer can write programs that match or exceed the quality of equivilent C programs written by equally skilled C programmers.

The development cycle of embedded software does not easily lend itself to the trial-and-error style of programming and debugging, so a stubborn C++ compiler that catches as many errors as possible at compile time significantly reduces the dependence on run-time debugging, executable run-time support and compile/download/test cycles. This saves untold hours at the test bench, not to mention strain on PROM sockets.



Stephen Williams
Sun May 4 15:28:26 PDT 1997