RES: RES: RTEMS with C++

Mon Nov 6 12:25:20 UTC 2006

Steve,

Thank you very much for the experience you shared. I'll use your information
with the info people from the list gave before to try to convince my group.
Thanks again!

Regards,

Fabricio.

-----Mensagem original-----
De: rtems-users-bounces at rtems.org
[mailto:rtems-users-bounces at rtems.org]Em nome de Steve Strobel
Enviada em: sexta-feira, 3 de novembro de 2006 15:18
Para: RTEMS Users
Assunto: Re: RES: RTEMS with C++

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

_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users