By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,124 Members | 950 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,124 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.

Jan 3 '07 #1
Share this Question
Share on Google+
42 Replies


P: n/a
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
Jan 3 '07 #2

P: n/a

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.

Jan 3 '07 #3

P: n/a
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.

Jan 3 '07 #4

P: n/a

"bjeremy" <bj*****@sbcglobal.netwrote in message
news:11********************@42g2000cwt.googlegroup s.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
Jan 3 '07 #5

P: n/a
Serve Laurijssen a écrit :
"bjeremy" <bj*****@sbcglobal.netwrote in message
news:11********************@42g2000cwt.googlegroup s.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
Jan 3 '07 #6

P: n/a
Serve Laurijssen wrote:
"bjeremy" <bj*****@sbcglobal.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>
Jan 3 '07 #7

P: n/a
On 2 Jan 2007 18:14:32 -0800, "bjeremy" <bj*****@sbcglobal.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
Jan 3 '07 #8

P: n/a
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...
Jan 3 '07 #9

P: n/a
Al Balmer wrote:
On 2 Jan 2007 18:14:32 -0800, "bjeremy" <bj*****@sbcglobal.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.
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.
Jan 3 '07 #10

P: n/a

Serve Laurijssen wrote:
"bjeremy" <bj*****@sbcglobal.netwrote in message
news:11********************@42g2000cwt.googlegroup s.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
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.

Jan 3 '07 #11

P: n/a

Al Balmer wrote:
>>
bjeremy wrote:
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.
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).

Jan 4 '07 #12

P: n/a

Serve Laurijssen wrote:
"bjeremy" <bj*****@sbcglobal.netwrote in message
news:11********************@42g2000cwt.googlegroup s.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
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.

Jan 4 '07 #13

P: n/a
Baron Samedi wrote:
>
.... 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.

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

P: n/a
In article <11**********************@h40g2000cwb.googlegroups .com>,
Baron Samedi <Pa************@gmail.comwrites
>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 Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 4 '07 #15

P: n/a
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Serve Laurijssen wrote:
>"bjeremy" <bj*****@sbcglobal.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.
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 Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 4 '07 #16

P: n/a
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Baron Samedi wrote:
>>
... 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.
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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 4 '07 #17

P: n/a
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

Jan 4 '07 #18

P: n/a
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

Jan 4 '07 #19

P: n/a
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

Jan 4 '07 #20

P: n/a
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?

Jan 4 '07 #21

P: n/a

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

Jan 4 '07 #22

P: n/a
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
Jan 4 '07 #23

P: n/a
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
Jan 4 '07 #24

P: n/a
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>
Jan 5 '07 #25

P: n/a
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>
Jan 5 '07 #26

P: n/a
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.
Jan 5 '07 #27

P: n/a
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.
Jan 5 '07 #28

P: n/a
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?

Jan 5 '07 #29

P: n/a

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

Jan 5 '07 #30

P: n/a

Al Balmer schrieb:
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.
Hmm ... but ... sometimes someone makes an error just by accident. You
know, we are human beings... ;o)

Henryk

Jan 5 '07 #31

P: n/a
Henryk a écrit :
Al Balmer schrieb:
>>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
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.

Jan 5 '07 #32

P: n/a
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
Jan 5 '07 #33

P: n/a
On Jan 5, 6:56 am, CBFalconer <cbfalco...@yahoo.comwrote:
Henryk wrote:
<snip>
Why did you post this 3 times? Usenet is not an instantaneous
medium. Time to propagate ranges from millisecs to infinity.
If you post through google, it will sometimes report that the post
wasn't successful and that it should be retried later. Nevertheless,
that message may appear at a later time (or it may not, you never
know). I once posted 8 messages like that (luckily, not to c.l.c =).
--
WYCIWYG - what you C is what you get

Jan 5 '07 #34

P: n/a
Henryk wrote:
CBFalconer schrieb:
Henryk wrote:
<snip repeated post>
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...
Not even there.

Jan 5 '07 #35

P: n/a
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.
So lcc-win32 fails to detect a syntactic error caused by an easy
typo.

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

Jan 5 '07 #36

P: n/a
CBFalconer wrote:
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.

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.

Jan 5 '07 #37

P: n/a
santosh wrote:
CBFalconer wrote:
>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.

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.
Or on W98 executing on a 486. Contrary to Jacobs claim of W98
compatibility. Please read the underlined query I made originally.

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

P: n/a
On Fri, 05 Jan 2007 11:56:42 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Henryk a écrit :
>Al Balmer schrieb:
>>>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

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
Jan 6 '07 #39

P: n/a
On Fri, 5 Jan 2007 02:38:05 -0600, Richard Heathfield wrote
(in article <Ev******************************@bt.com>):
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).
Works for me. :-)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 10 '07 #40

P: n/a
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

Jan 10 '07 #41

P: n/a
On Thu, 4 Jan 2007 07:56:11 -0600, Henryk wrote
(in article <11*********************@i15g2000cwa.googlegroups. 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

Jan 10 '07 #42

P: n/a
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*********************@i15g2000cwa.googlegroups. 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
Jan 10 '07 #43

This discussion thread is closed

Replies have been disabled for this discussion.