RES: RTEMS with C++

[Steve Strobel]

At 10:09 AM 10/11/2006, you wrote:
>Angelo, Leon, Chrises (Welch and Johns ;-)
>
>Thank you for your answers.
>
>Good to know that I'm wrong about RTEMS and C++, but I have to convince some
>other people here too.
>
>We'll start developing new software for the space area in C. We already have
>experience with software for satellites, but using assembly - ok, *I* don't
>have; I'm the new guy here.

My experience is that using the C++ compiler will cost you virtually 
nothing in performance if you don't use the expensive C++ features, 
and provides some benefits such as:
- Possibly improved type checking
- Inline functions (the efficiency of macros without the headaches)
- The ability to overload functions based on the data type (resolved 
at compile time so it doesn't add overhead)
- The ability to declare variables where they are needed rather than 
at the beginning of the function (some may not like that style, but I do)
- The flexibility to gradually move toward object oriented 
programming if desired (you won't want to go back to straight C)

You can avoid the overhead often associated with C++ by skipping 
things like exceptions, RTTI, STL and I/O streams.  You may be able 
to turn some of them off with compiler switches (RTTI and exceptions) 
and just not use STL and I/O streams.  That being said, consider 
carefully how much extra work it is worth to save a few bytes and 
processor cycles up front.

For example, when starting one project I compared a simple "Hello 
World" program with printf versus with cout and found that the cout 
version took 40KB more space, a huge percentage jump for such a 
simple program.  I chose to stick with printf and friends and dug 
into development.  A few years later we decided to add an option to 
the product that required I change a lot of the internal variables 
from 32-bit to 64-bit integers.  Of course that changed all of my 
formatting strings and matching input functions for the user 
interface, debugging, remote control and persistence.  I ended up 
ripping out the print-related stuff and replacing it all with 
iostreams.  At that point the executable was 1500KB, and a 40KB jump 
to include the iostreams library was completely insignificant.  Your 
mileage may vary.

I personally avoid the STL (standard template library) in most cases 
because of its heavy reliance on dynamic memory allocation.  I prefer 
to pre-allocate a pool of memory for each buffer (either at compile 
time or as a single dynamically allocated block at runtime) so I know 
that if it compiles and runs that it won't fail later because of 
memory exhaustion or fragmentation (or if it does, the buffer that is 
using too much memory will be the one that fails, rather than causing 
a problem somewhere else in the system).  In other applications, the 
STL might work great.

I don't use the standard RTTI mechanism, but I do use similar 
functionality for a few classes.  See Bruce Eckel's article about it 
in the Feb 1995 issue of Embedded Systems Programming if you need 
something similar.

Exceptions add overhead, but so does robust error checking code.  If 
you don't use exceptions, you could consider using one of the methods 
for "encouraging" the checking of returned error codes.  Search for 
"Mandatory Error Codes" and "Mandatory Error Codes Revisited" on 
http://www.ddj.com or email me if you are interested.

I would suggest not fighting the battle over what style of code to 
write at this point, but to just encourage using the C++ compiler for 
all files even if they are plain C.  I think that everyone will 
benefit from the improved type checking, and those that want to can 
begin to use it as a "better C".  Don't try to mix C and C++ files or 
you will have to deal with the calling conventions (extern "C" and 
the like).  Eventually your team may decide to take the jump to 
object oriented design, but that is a subject for another day.

Steve



---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel at link-comm.com