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.

[santosh]

Henryk wrote:

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

<snip>

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

What typical C memory access errors?

[Henryk]

santosh schrieb:

Henryk wrote:

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

<snip>

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

What typical C memory access errors?

You know what I mean ... ;o)

All those little pitfalls due to messing around with pointers. Using
references and proper initialized objects in C++ can avoid most of
these errors and saves us from checking pointers again and again for
validity when handed around within an application...

Of course you can mess around with references too but its much harder
to do so just by accident.

Henryk

[Al Balmer]

On 4 Jan 2007 08:56:55 -0800, "Henryk" <he************ @gmx.dewrote:

>
santosh schrieb:

>Henryk wrote:

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

<snip>

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

What typical C memory access errors?

You know what I mean ... ;o)

All those little pitfalls due to messing around with pointers. Using
references and proper initialized objects in C++ can avoid most of
these errors and saves us from checking pointers again and again for
validity when handed around within an application...

Sounds like a poorly designed application.

>
Of course you can mess around with references too but its much harder
to do so just by accident.

Maybe that's the difference. I don't write code by accident.

--
Al Balmer
Sun City, AZ

[jacob navia]

Henryk a écrit :

santosh schrieb:

>>Henryk wrote:

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

<snip>

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

What typical C memory access errors?

You know what I mean ... ;o)

All those little pitfalls due to messing around with pointers. Using
references and proper initialized objects in C++ can avoid most of
these errors and saves us from checking pointers again and again for
validity when handed around within an application...

Of course you can mess around with references too but its much harder
to do so just by accident.

Henryk

That's why I inroduced references in lcc-win32 C compiler

jacob
P.S. flames >/dev/null

[CBFalconer]

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?

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

[CBFalconer]

Henryk wrote:

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

Why did you post this 3 times? Usenet is not an instantaneous
medium. Time to propagate ranges from millisecs to infinity.

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

[Richard Heathfield]

CBFalconer said:

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?

One surefire method would be to use gcc (avec incantations).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jacob navia]

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.

[santosh]

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?

[Henryk]

CBFalconer schrieb:

Henryk wrote:

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.

Why did you post this 3 times? Usenet is not an instantaneous
medium. Time to propagate ranges from millisecs to infinity.

Sorry about that! My network browser did not respond so I thought it
was not sent. I deleted the posts later, but maybe this works only in
the google groups...

Henryk