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]

Baron Samedi wrote:

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.

--
Salu2

[bjeremy]

Baron Samedi wrote:

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]

bjeremy wrote:

Baron Samedi wrote:

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.

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]

"bjeremy" <bj*****@sbcglo bal.netwrote in message
news:11******** ************@42 g2000cwt.google groups.com...

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 :

"bjeremy" <bj*****@sbcglo bal.netwrote in message
news:11******** ************@42 g2000cwt.google groups.com...

>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

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]

Serve Laurijssen wrote:

"bjeremy" <bj*****@sbcglo bal.netwrote in message

>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

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Al Balmer]

On 2 Jan 2007 18:14:32 -0800, "bjeremy" <bj*****@sbcglo bal.netwrote:

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.

--
Al Balmer
Sun City, AZ

[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]

Al Balmer wrote:

On 2 Jan 2007 18:14:32 -0800, "bjeremy" <bj*****@sbcglo bal.netwrote:

>>no matter how good your intentions are, using C is a maintainence
nightmare. Not to mention extensibility and code reuse will suffer
dramaticall y 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.

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.

--
Ian Collins.