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

[santosh]

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

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]

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]

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.

 

[jacob navia]

Henryk a écrit :

santosh schrieb:




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]

.... snip ...

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

How do you disable them, and ALL the other extensions?

 

[CBFalconer]

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.

 

[Richard Heathfield]

CBFalconer said:

How do you disable them, and ALL the other extensions?

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

 

[jacob navia]

CBFalconer a écrit :

jacob navia wrote:

... snip ...



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]

CBFalconer a écrit :
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]

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

 

[Henryk]

Sounds like a poorly designed application.

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

Hmm ... but ... sometimes someone makes an error just by accident. You
know, we are human beings... ;o)

Henryk

 

[jacob navia]

Henryk a écrit :

Hmm ... but ... sometimes someone makes an error just by accident. You
know, we are human beings... ;o)

Henryk

Look Henryk, we are speaking about human beings, not about
beings like "Al Balmer" that never has an accident, never
make any errors and in general is high above us simple mortals.

 

[jacob navia]

santosh a écrit :

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

 

[santosh]

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

Not even there.

 

[CBFalconer]

CBFalconer a écrit :

No need to disable them, since you use them only if
you explicitely write
int &a = b;

You just do not use that.

So lcc-win32 fails to detect a syntactic error caused by an easy
typo.

 

[santosh]

So lcc-win32 fails to detect a syntactic error caused by an easy typo.

It isn't a typo in the lcc-win32 language. To coerce the compiler to
compile C90, apparently, you've to supply the -ansic switch.

I would test it if I had Windows. wedit refuses to run under Wine.

 

[CBFalconer]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It isn't a typo in the lcc-win32 language. To coerce the compiler to
compile C90, apparently, you've to supply the -ansic switch.

I would test it if I had Windows. wedit refuses to run under Wine.

Or on W98 executing on a 486. Contrary to Jacobs claim of W98
compatibility. Please read the underlined query I made originally.

 

[Mark McIntyre]

Henryk a écrit :

Look Henryk, we are speaking about human beings, not about
beings like "Al Balmer" that never has an accident, never
make any errors and in general is high above us simple mortals.

Ignoring the ad hominem rudeness, the point Al was making is that the
error in question isn't one you can accidentally make very easily,
unless you're writing C++ by accident.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Randy Howard]

CBFalconer said:


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

Works for me.

 

[Randy Howard]

santosh a écrit :

Yes. Use the -ansic switch

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