C or C++ for embedded system plug-in?

[Baron Samedi]

I want to produce a piece of software for embedded systems, generally
telecoms based, mostly running on ARM processors, but I can't guarantee
that, of course.

My software should work along with other software which will generally
be written in C or C++ (occasionally in ADA or even assembler).

I suppose that there are C compilers for marginally more processors
than C++, but, realistically, I am not sure that it makes a major
difference.

I suppose that C produces slightly smaller and faster code, but wonder
if it makes a major difference.

I like C++ exception handling (but know 6that it adds an overhead). I
have clearly defined interfaces and interfacing software would gain
nothing really by instantiating any classes, if I used C++

I want to genericize functionality which the host software ought to
provide, so that I can use their memory allocation routines, timers,
debug tracing, etc, etc - probably just by offering some #defines,
which they can change in a single header file, as necessary - but any
advice is welcome.

I think that I am leaning towards C, but am open to input ...

Thanks in advance for any help.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

I want to produce a piece of software for embedded systems, generally
telecoms based, mostly running on ARM processors, but I can't guarantee
that, of course.
My software should work along with other software which will generally
be written in C or C++ (occasionally in ADA or even assembler).

In the majority of cases you just need a way to provide functions with C
linkage and calling conventions, to be able to call him from another
languages. Most language implementations provide ways to do that, then you
can choose what language to use based in other requirements or preferences.

 

[bjeremy]

I want to produce a piece of software for embedded systems, generally
telecoms based, mostly running on ARM processors, but I can't guarantee
that, of course.

My software should work along with other software which will generally
be written in C or C++ (occasionally in ADA or even assembler).

I suppose that there are C compilers for marginally more processors
than C++, but, realistically, I am not sure that it makes a major
difference.

I suppose that C produces slightly smaller and faster code, but wonder
if it makes a major difference.

I like C++ exception handling (but know 6that it adds an overhead). I
have clearly defined interfaces and interfacing software would gain
nothing really by instantiating any classes, if I used C++

I want to genericize functionality which the host software ought to
provide, so that I can use their memory allocation routines, timers,
debug tracing, etc, etc - probably just by offering some #defines,
which they can change in a single header file, as necessary - but any
advice is welcome.

I think that I am leaning towards C, but am open to input ...

Thanks in advance for any help.

I work on embedded systems for a large networking company. I work in
the packet core on UMTS & GPRS GSN nodes. Our various GSN nodes differ
in implementation our SGSN was written in C++ (however the compiler is
very old and some of the features were disabled for whatever reason)
and our GGSN was written in C, mainly since we inherited a lot of base
routing, service and subscriber managment code written in C. Although I
like working on our GGSN, mostly for the IP Service development, I urge
you... if you are starting a project and have a choice.. use C++.... no
matter how good your intentions are, using C is a maintainence
nightmare. Not to mention extensibility and code reuse will suffer
dramatically depending on the size of your project. Some code may still
be needed to be written in Assembly or C (i.e. any special hardware
like a fast ethernet line card would probably still need to be
programmed in assembly for performance reasons).

As for performance in C compared with C++, what I mainly seen are the
capacity issues deal more with the design of the system. And C++
provides less rope to hang yourself with than C.

 

[Baron Samedi]

I work on embedded systems for a large networking company. I work in
the packet core on UMTS & GPRS GSN nodes. Our various GSN nodes differ
in implementation our SGSN was written in C++ (however the compiler is
very old and some of the features were disabled for whatever reason)
and our GGSN was written in C, mainly since we inherited a lot of base
routing, service and subscriber managment code written in C. Although I
like working on our GGSN, mostly for the IP Service development, I urge
you... if you are starting a project and have a choice.. use C++.... no
matter how good your intentions are, using C is a maintainence
nightmare. Not to mention extensibility and code reuse will suffer
dramatically depending on the size of your project. Some code may still
be needed to be written in Assembly or C (i.e. any special hardware
like a fast ethernet line card would probably still need to be
programmed in assembly for performance reasons).

As for performance in C compared with C++, what I mainly seen are the
capacity issues deal more with the design of the system. And C++
provides less rope to hang yourself with than C.

Thanks for the great reply (and quick too).

Basically, I want to have a common adaptation layer for
handsets/modems/terminal adapters which sits above the protocol stack
(AS/NAS, Layers 1 to 3) and offers a 24.007 interface at one side and a
generic interface to different device drivers (USB, Ethernet, etc),
probably appearing as a virtual serial port.

The code probably won't be extensible by the end user, and I don't see
them instantiating any objects, but I do like C++.

As I stated, there will be fixed interfaces on both sides, one defined
by CCITT/ETSI/3GPP and the other abstracting device drivers, so
probably Virtual Serial Port. Users only get to tweak a few macros to
determine how my software allocates memory, performs debug tracing,
handles timers and the like.

You have certainly given me food for thought. Thanks.

 

[Serve Laurijssen]

As for performance in C compared with C++, what I mainly seen are the
capacity issues deal more with the design of the system. And C++
provides less rope to hang yourself with than C.

In your opinion of course. In MY opinion C++ provides all the rope you can
hang yourself with as in C plus a whole lot extra. But you shouldnt worry
about that at all if you have competent programmers. C and C++ are both
great languages that get the job done from the lowest level to the highest.
If I had the choice of language for a next project I would choose what I
like best and not ask advice from biased newsgroup people

 

[Michael DOUBEZ]

Serve Laurijssen a écrit :

In your opinion of course. In MY opinion C++ provides all the rope you can
hang yourself with as in C plus a whole lot extra. But you shouldnt worry
about that at all if you have competent programmers. C and C++ are both
great languages that get the job done from the lowest level to the highest.
If I had the choice of language for a next project I would choose what I
like best and not ask advice from biased newsgroup people

In truth, I have seen many good C programmers wanting to hang themselves
when they learned they would have to code in C++

For further reading, you can try this article:
http://www.ganssle.com/articles/alingo.htm

Michael

 

[CBFalconer]

In your opinion of course. In MY opinion C++ provides all the rope
you can hang yourself with as in C plus a whole lot extra. But you
shouldnt worry about that at all if you have competent programmers.
C and C++ are both great languages that get the job done from the
lowest level to the highest. If I had the choice of language for a
next project I would choose what I like best and not ask advice
from biased newsgroup people

If you want a widely available language and maximum safety use Ada.

 

[Al Balmer]

no
matter how good your intentions are, using C is a maintainence
nightmare. Not to mention extensibility and code reuse will suffer
dramatically depending on the size of your project.

I have a different opinion. If you have the stated problems with C,
they are due more to your programmers than the language. C can be
written to be easily maintainable, extensible, and reusable. In fact,
I've seen many cases where the initial partitioning of the problem and
resulting choice of classes made C++ code much more of a problem in
maintenance, extensibility, and reuse.

C++ which takes advantage of OO techniques often ends up "all of a
piece", and disturbing one portion perturbs everything else. It's
possible to design programs using classes which are nicely extensible
and reusable, but it's difficult and time consuming, and all too
seldom done properly.

 

[jacob navia]

Al Balmer a écrit :

C++ which takes advantage of OO techniques often ends up "all of a
piece", and disturbing one portion perturbs everything else.

Specially if everything is done in constructors, making it
very difficult to take out one part of that code...

 

[Ian Collins]

I have a different opinion. If you have the stated problems with C,
they are due more to your programmers than the language.

Programmers or process.

C can be
written to be easily maintainable, extensible, and reusable.

As can any language, even assembly.

In fact,
I've seen many cases where the initial partitioning of the problem and
resulting choice of classes made C++ code much more of a problem in
maintenance, extensibility, and reuse.

That's one reason why BDUF is a mistake.

C++ which takes advantage of OO techniques often ends up "all of a
piece", and disturbing one portion perturbs everything else. It's
possible to design programs using classes which are nicely extensible
and reusable, but it's difficult and time consuming, and all too
seldom done properly.

I agree, that's why OO designs (in any language) should evolve rather
that be done up front.

 

[bjeremy]

In your opinion of course. In MY opinion C++ provides all the rope you can
hang yourself with as in C plus a whole lot extra. But you shouldnt worry
about that at all if you have competent programmers. C and C++ are both
great languages that get the job done from the lowest level to the highest.
If I had the choice of language for a next project I would choose what I
like best and not ask advice from biased newsgroup people

This is probably not the case for the OP... but as to the above comment
the relevent term here is "competent programmers". A lot of shops do a
significant amount of outsourcing which has a number of problems. One
of them is *NOT* that there are no competent contractors in India,
Vietname, China, or other countries, the problem is that most companies
will not pay for them. I've seen them again and again try and get the
contractors for the lowest pay they can. This does not draw top talent.
(i.e. While Infosys has a lot of IIT grads, I have only worked with
one, of course he was very capable.)

This also creates an attrition effect. As more and more contractors who
work on your project become competent, they will leave for a more
lucrative offer. This all but guarantees that you will have a fresh
stream of "new hires" working on your system every 3 to 6 months.

I have also noticed a significant portion of the development cycle lost
due to communications between Designers on two sides of the globe
communicating mainly through email. Since we are usually 11 or more
hours appart it usually takes days to resolve a problem.

In an environment such as this (And I understand this does not apply to
all shops), I would have to say IMO ***maintainability of the existing
software is paramount to all else***. Easily understandable code makes
for less ramp up time, and it seems fewer software bugs introduced
during bug fixes and and/or redesign of existing systems, and it also
creates a more autonomous working evironment where communication, while
still necessary, is limited and less likely to cause delays.

 

[Grizlyk]

I have a different opinion. If you have the stated problems with C,
they are due more to your programmers than the language. C can be
written to be easily maintainable, extensible, and reusable. In fact,
I've seen many cases where the initial partitioning of the problem and
resulting choice of classes made C++ code much more of a problem in
maintenance, extensibility, and reuse.

I think, if you are not using OO design, C++ is generaly equal to C.

But in addition, for C++ you can use classes as ATD (abstract data
types) created by composition (without inheritance, design patterns and
so on). In other words, you can use classes as impoved C modules and
types. You can also use C++ overloading for functions.

C can be more compatible than C++ for cross-platforms works due to more
limited C features and more simple rules, that can be easy understanded
by programmer without confusions. (The most simple rules is ASM (mov
ax,bx), but hundreads of lines of asm is absolutely unreadable).

 

[Baron Samedi]

In your opinion of course. In MY opinion C++ provides all the rope you can
hang yourself with as in C plus a whole lot extra. But you shouldnt worry
about that at all if you have competent programmers. C and C++ are both
great languages that get the job done from the lowest level to the highest.
If I had the choice of language for a next project I would choose what I
like best and not ask advice from biased newsgroup people

A valid point, but I am happy with both. I will admit that most of my
professional work (telecomms) is C, and most of my hobby programming is
C++ (windows programs with GUIS0, so I have some - but not too much -
experience of C++ in embedded systems. That's why I asked. I was
interested in what others have thought.

To be honest, I am not too hung up on programming language. When
recruiting, I always consider telecoms experience as the prime
importance. FRO C projects, I don't care about language experience ;
for C++, I prefer some C++, or other OO.

A few years ago I worked for a company which was fixated on ADA. They
recruited a whole team to do a protocol stack. None of us had any ADA
experience, but we turned out a good product.

 

[CBFalconer]

.... snip ...

A few years ago I worked for a company which was fixated on ADA.
They recruited a whole team to do a protocol stack. None of us
had any ADA experience, but we turned out a good product.

Which says something about the reliability of Ada.

 

[Chris Hills]

I want to produce a piece of software for embedded systems, generally
telecoms based, mostly running on ARM processors, but I can't guarantee
that, of course.

Then try comp.arch.embedded they understand embedded systems and
hardware.

My software should work along with other software which will generally
be written in C or C++ (occasionally in ADA or even assembler).

I suppose that there are C compilers for marginally more processors
than C++, but, realistically, I am not sure that it makes a major
difference.

There are a LOT more C than C++ compilers. Especially for the smaller
micros. Also I think you will find it is easier to interface the other
languages to C than C++

I suppose that C produces slightly smaller and faster code, but wonder
if it makes a major difference.

Depends on your compiler(s) and target platform. It might make a major
difference but then again it may not.

I like C++ exception handling (but know 6that it adds an overhead). I
have clearly defined interfaces and interfacing software would gain
nothing really by instantiating any classes, if I used C++

These may not be supported by all C++ compilers fro embedded targets.

 

[Chris Hills]

If you want a widely available language and maximum safety use Ada.

Compared to C ADA is not widely available or supported.

As for Maximum safety... you can make a mess in Ada just as much as any
other language. For maximum safety you could use SPARK but that is
even less available.

BTW which language did they choose for the US Joint Strike Fighter?
(Do you know why? )

 

[Chris Hills]

Which says something about the reliability of Ada.

It doesn't say anything about Ada... They might have been just as
successful in Mod2, Pascal, Chill, Fortran etc

It does say something about the team though.

 

[Henryk]

We made very good experience with C++ on embedded systems even for time
critical tasks.

For our system we restricted the C++ features that are allowed. Those
are:
- no dynamic memory allocation (no new, delete, malloc, free etc.)
- no exceptions
- no run time type information
- no virtual functions
- no templates

Some of the restrictions were due to the first platform we used
(compiler did not support templates) others were choosen to increase
robustness and speed.

The resulting software is very modular and and code is easy to read. We
almost never had any of those typical C memory access errors...

The great benefits of C++ over C in this projects are:
- excessive usage of references instead of pointers makes the code very
robust
- excessive usage of const classifiers avoids mis-usage of objects
- class access rights + lightweight inline methods (set, get) assure
protection of internal module variables. Old projects were full of
those evil extern declarations...
- constructors assure proper initialized modules
- all of those features above come with virtual no runtime overhead.

One of the disadvantage of C++ is a slightly greater memory footprint
because C++ environment initialization is more sophisticated...

I really like the beauty of our lightwight wrappers for hardware
interfaces. Almost no runtime-overhead, intuitive usage, and very
robust against abuse at the same time. Much better than anything that
you can achieve in C.

Our experience with C++ on embedded systems were so good that we use C
only for those platform that does not provide a proper C++ compiler.

Henryk

 

[Henryk]

We made very good experience with C++ on embedded systems even for time
critical tasks.

For our system we restricted the C++ features that are allowed. Those
are:
- no dynamic memory allocation (no new, delete, malloc, free etc.)
- no exceptions
- no run time type information
- no virtual functions
- no templates

Some of the restrictions were due to the first platform we used
(compiler did not support templates) others were choosen to increase
robustness and speed.

The resulting software is very modular and and code is easy to read. We
almost never had any of those typical C memory access errors...

The great benefits of C++ over C in this projects are:
- excessive usage of references instead of pointers makes the code very
robust
- excessive usage of const classifiers avoids mis-usage of objects
- class access rights + lightweight inline methods (set, get) assure
protection of internal module variables. Old projects were full of
those evil extern declarations...
- constructors assure proper initialized modules
- all of those features above come with virtual no runtime overhead.

One of the disadvantage of C++ is a slightly greater memory footprint
because C++ environment initialization is more sophisticated...

I really like the beauty of our lightwight wrappers for hardware
interfaces. Almost no runtime-overhead, intuitive usage, and very
robust against abuse at the same time. Much better than anything that
you can achieve in C.

Our experience with C++ on embedded systems were so good that we use C
only for those platform that does not provide a proper C++ compiler.

Henryk

 

[Henryk]

We made very good experience with C++ on embedded systems even for time
critical tasks.

For our system we restricted the C++ features that are allowed. Those
are:
- no dynamic memory allocation (no new, delete, malloc, free etc.)
- no exceptions
- no run time type information
- no virtual functions
- no templates

Some of the restrictions were due to the first platform we used
(compiler did not support templates) others were choosen to increase
robustness and speed.

The resulting software is very modular and and code is easy to read. We
almost never had any of those typical C memory access errors...

The great benefits of C++ over C in this projects are:
- excessive usage of references instead of pointers makes the code very
robust
- excessive usage of const classifiers avoids mis-usage of objects
- class access rights + lightweight inline methods (set, get) assure
protection of internal module variables. Old projects were full of
those evil extern declarations...
- constructors assure proper initialized modules
- all of those features above come with virtual no runtime overhead.

One of the disadvantage of C++ is a slightly greater memory footprint
because C++ environment initialization is more sophisticated...

I really like the beauty of our lightwight wrappers for hardware
interfaces. Almost no runtime-overhead, intuitive usage, and very
robust against abuse at the same time. Much better than anything that
you can achieve in C.

Our experience with C++ on embedded systems were so good that we use C
only for those platform that does not provide a proper C++ compiler.

Henryk