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.

[Randy Howard]

On Fri, 5 Jan 2007 04:57:31 -0600, jacob navia wrote
(in article <45************ **********@news .orange.fr>):

santosh a écrit :

>jacob navia wrote:

>>CBFalconer a écrit :

jacob navia wrote:
... snip ...
That's why I inroduced references in lcc-win32 C compiler

How do you disable them, and ALL the other extensions?
No need to disable them, since you use them only if
you explicitely write
int &a = b;

You just do not use that.

But there should be a mode in which the compiler produces a diagnostic
and possibly halts compilation for sources having non-C90 and/or
non-C99 constructs.

For lcc-win32 what are the switches or flags which turn on this
behaviour?

Yes. Use the -ansic switch

Which generates C89? Is there something for ISO standard C?

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Randy Howard]

On Thu, 4 Jan 2007 07:56:11 -0600, Henryk wrote
(in article <11************ *********@i15g2 000cwa.googlegr oups.com>):

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

So why use it?

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...

Strange, I use C instead of C++ and don't have "typical C memory access
errors". What are you referring to, specifically?

The great benefits of C++ over C in this projects are:
- excessive usage of references instead of pointers makes the code very
robust

How does it make it more robust? Do you really mean that it helps
programmers who don't know C and pointers very well?

- excessive usage of const classifiers avoids mis-usage of objects

Is it excessive, or not? :-)

- class access rights + lightweight inline methods (set, get) assure
protection of internal module variables. Old projects were full of
those evil extern declarations...

Ah, so you don't have C-literate programmers. You might want to
investigate how ADT's are properly implemented in C.

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

That's ok, embedded platforms always have plenty of memory. :-)

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.

Who "abuses" embedded software, other than the implementor(s)?

Much better than anything that you can achieve in C.

Not true. Perhaps you meant to write "I" instead of "you".

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Lionel B]

On Wed, 10 Jan 2007 00:24:48 +0000, Randy Howard wrote:

On Thu, 4 Jan 2007 07:56:11 -0600, Henryk wrote
(in article <11************ *********@i15g2 000cwa.googlegr oups.com>):

>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

So why use it?

>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...

Strange, I use C instead of C++ and don't have "typical C memory access
errors". What are you referring to, specifically?

I suspect he meant such things as attempting to dereference a pointer to
NULL or to the "wrong" area of memory, forgetting to deallocate memory
(memory leakage), reading/writing past the end of an array or memory
buffer, ...

C++ does have mechanisms lacking in C to assist in avoiding these errors,
such as the ability to do memory allocation/deallocation in
constructors/destructors, overloading of operators to implement array
bounds checking and ...

>The great benefits of C++ over C in this projects are:
- excessive usage of references instead of pointers makes the code very
robust

How does it make it more robust? Do you really mean that it helps
programmers who don't know C and pointers very well?

It is possible, but you have to be almost wilfully perverse, to initialise
a reference with a NULL/invalid address.

>- excessive usage of const classifiers avoids mis-usage of objects

Is it excessive, or not? :-)

Perhaps "consistent usage wherever appropriate" might have been a better
phrase :)

>- class access rights + lightweight inline methods (set, get) assure
protection of internal module variables. Old projects were full of
those evil extern declarations...

Ah, so you don't have C-literate programmers. You might want to
investigate how ADT's are properly implemented in C.

Perhaps "properly implementable" might be more accurate. I would suggest
that C++ makes encapsulation and object access control easier than it is
in C.

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

That's ok, embedded platforms always have plenty of memory. :-)

>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.

Who "abuses" embedded software, other than the implementor(s)?

The authors of software which accesses an API/interface to an embedded
system? I think what was intended is that it's easier in C++ than in C to
close off avenues of possible "abuse" - eg. by not exposing data/methods
that should not be accessed by the user of an interface to your system.

>Much better than anything that you can achieve in C.

I'd prefer "more easily than can be achieved in C".

Not true. Perhaps you meant to write "I" instead of "you".

Possibly that too ;)

--
Lionel B