C++ in embedded systems - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: C++ in embedded systems

Quoted text here. Click to load it

I think I have met 3 of them.



Re: C++ in embedded systems
Quoted text here. Click to load it

As a C++ developer for embedded systems with some twenty years of toil
behind me, I have nothing but respect for Forth developers. I envy the fact
that they can develop interactively and be running code on new hardware in
minutes. We have many more obstilces in our way (compiler, linker, debug
target, download agent, debug client; all of these have to work before
anything works). We work far from the hardware; forth developers are in
contact with it.

Quoted text here. Click to load it



Re: C++ in embedded systems

Quoted text here. Click to load it
Tee hee. But if it was true, I would have been out of business
long ago. Modern Forth compilers produce good code, and where
code density matters, Forth still produces applications that
are often half the size of C applications. And yes, I do
have numbers to back this up for a payment terminal (8051)
and an embedded web server (68xxx, H8S and ARM).

Quoted text here. Click to load it
Very true. I would also add that with the exception of web weenies,
very few junior programmers have used any languages other than
C/C++ and perhaps Java. This in distinct comparison from 15 years
ago, when most programmers in any field had actually used a
much wider range of languages and had the experience to be able
to select an appropriate language for a job. If you have never
used interactive languages, you will never be able to appreciate
what they have to offer. Remember Smalltalk, Eiffel, BASIC ...
Any community misses out if its focus is on a range of culturally
similar languages, programming or spoken.

Quoted text here. Click to load it
Apart from OO (the current silver bullet), there is little to
separate any of the batch compiled languages such as C, C++,
Pascal and so on. At least Modula 2 dealt with the dependency
issues.

Quoted text here. Click to load it
It is August and the silly season is upon us :-)

Stephen

--
Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
In most "embedded designs," I either use assembler or C++ and assembler.  In
particular, GCC's in-line assembler is extremely powerful (once you get the
hang of it).  In my experience, I have not run across any situation where I
could find a performance advantage between C and C++ -- if the processor has
the architecture and performance headroom to support C it will also support
C++.

The C++ advantages and drawbacks are like everything else in a tight
design -- you have to be sure you can afford the convenience.  This judgment
comes from experience, and it may be that most C++ programmers work in the
user application space where efficient coding often does not bring
performance advantage to the overall enterprise system.  After all, if you
are shoveling megabytes XML across your 1.544 mb/s internet connection, who
gives a flip whether you tighten up some inner loop with hand done assembly
language?  But for real embedded work, where you are trying to shoehorn the
product into the cheapest microprocessor with the fewest resources, here are
some advantages over C that C++ brings to the table:

1. Classes.  It's very nice in embedded systems to organize pieces of
hardware into objects.  For instance, in a very tight AVR project where I am
counting cycles, I have a class that wraps the SPI port with an interrupt
handler, several command methods, a foreground routine, and logic code to
generate and decode packets sent to/from an FPGA.  I did it this way to make
it simple for me and the FPGA designer to stay on the same page, even
editing each others code.  But after we were done, I abandoned plans to
tighten up its performance.  It is better than I could do with straight
assembler, and it's more than fast enough.

2. overridden new/delete operators.  I can override new and delete
operators, swapping in a custom memory manager to replace "stock" dynamic
memory (malloc/free) support.  In designs where I need dynamic memory, but
can't afford a heap, this is a very nice way to get screaming performance in
a manner transparent to the application.

In my experience, here are some C++ features that may or may not be helpful:

1. Multiple inheritance.  This adds a lot of code and overhead to function
calls as your "this" pointer is transparently moved about.  In some cases, I
have used sloppy multiple inheritance to get a prototype running, but after
profiling, gone back and replaced some of it with explicit code.  However,
when simple member functions can be implemented inline, then the optimizer
usually completely removes the overhead.

2. Virtual Functions.  If you're playing tricks in C with function pointers
to add abstraction, sometimes C++ virtual base classes can do it better with
less opportunity for error.  This is not always the case, but in my
experience it sometimes works this way.

3. Overloaded operators.  I don't like this feature at all.  It doesn't
really add overhead, but it's confusing to me.  A lot of people love it
though.  Maybe it's a matter of taste.

Even very good people look at me askance when I say I uses C++ for embedded
applications.  However, it works for me.  I am able to bring projects in on
time and they work correctly.  It's tough times, and I am able to stay very
competitive with embedded C++.



Re: C++ in embedded systems
Quoted text here. Click to load it

You seem to be the exception to the rule.  As many others have said, C++ is
a large language, and thus, hard to learn all of it.  You don't seem to
have this problem.  Clearly, different people have different capacity to
effectively use C++.  But after reading 80 or so responses, I've concluded
that there are quite a few misconceptions about C and C++.  This is not
surprising considering this is comp.arch.embedded.  Because I assume most
respondants have a hardware background and moved into software.  You, on the
other hand, probably have a software background and moved into hardware.
This is certainly the case for me.

Because of my background, I would like to clear up some of the misconceptions.
The biggest misconception I've seen is the concept of object oriented
programming.  I get the feeling that not many people realize that C++ is
a multi-paradigm programming language.  There are many programming paradigms.
http://www.wikipedia.org/wiki/Programming_paradigm contains a list of them.
One important one not covered in this site is the generic programming
paradigm.

C++ supports three different programming paradigms; procedural, object
oriented and generic.  Procedural programming is supported through the
backward compatibility with C.  Object oriented programming is supported
through the classes and all of the features associated with them.  Generic
programming is supported through templates.  With three supported paradigms
is it any wonder that the language is large?  But this doesn't necessarily
mean the language is hard to learn.  Which is a subjective evaluation in
any case.  I.e. learning music is hard for me, but that doesn't mean sheet
music should be thrown out.

Once you understand that C++ supports multiple programming paradigms,
the other misconceptions become obvious.

1.  C++ is hard to learn.
    This is only the case if you are trying to use all three paradigms
    at once.  There's no requirement for this.  It also explains why
    the C++ standard is multiple times larger than other languages.
    Name me another language that supports multiple paradigms and
    then we can compare.

    I should also note that much of the C++ language standard text
    covers the standard library.  Which is an order of magnitude larger
    than most other languages.  The C++ language proper is mostly
    equivalent in size to other languages if you only compare the
    paradigms individually.

2.  C can simulate features of C++ (encapsulation, inheritance, etc).
    Any language can simulate most other languages.  But this doesn't
    mean you are shifting paradigms.  People assume that just because
    they use encapsulation (abstract data types), that they are doing
    object oriented programming.  This is a major misconception.
    Object oriented programming is not just about encapsulation and
    inheritance.  It is a methodology, a paramdigm shift.  Object
    oriented programming is a way of looking at the problem, and a
    way of looking at the solution to this problem.  This is explained
    in the URL link above.

    For those who have ported your C software to C++ and declare you're
    doing object oriented programming, ask yourself this question:
    did I perform a paradigm shift?  If the answer is no, then you
    aren't doing object orient programming.

3.  Rudimentary inheritance can be achieved with nested structures in C.
    This is a mistake people often make with object oriented programming.  
    First of all, nested structures in C is equivalent to C++ data
    composition.  This is not inheritance.  Second, inheritance involves
    more than just inheriting data variables, it also involves inheriting
    interfaces.  You can't do this in C.  When people talk about C++
    inheritance, they are often talking about the latter.

4.  C++ is bloated (binary wise)
    Whether your resulting binary is bloated or not is an implementation
    issue, not a language issue.  You can easily bloat any binary using
    any language.  For example, if I did a copy and paste of a block of
    code in C, then I've just bloated my final executable.  The difference
    between this and inline functions, and templates in C++, is that
    it is a lot easier to make this mistake in C++.  But this IS a
    mistake by the programmer, and not a inherent problem in the C++
    language.  You can't fault a language because there are a lot of
    poor C++ programmers.

    Of course, one could say that it is these faults in C++ that are
    producing so many poor programmers.  True, a good language should
    make it possible to use it effectively.  But ultimately, this is
    a catch 22.  Are the faults creating poor programmers, or are poor
    programmers faulting sound features of C++?  I guess it depends on
    who you ask.

5.  C++ is slow (compile and execution)
    For compilation, this is a problem with the tools, not the language.
    Though the language makes it harder for the tools.  As for execution,
    this is the same as #4 above.  Don't blame the language for the
    programmer's limited abilities.

    But note, even though most of the slow down is due to poor programming.
    There are inherent performance problems in C++, simply due to the
    object oriented paradigm.  The explanation for this is that, any
    performance lost, you gain in ease of maintenance, and you can
    always use a more powerful processor.

    I personally disagree with this line of thought.  As any embedded
    system engineer knows, you don't always have the extra 100 watt
    power supply for the Pentium4, or the extra 5cm square of real-
    estate for the fan.  Simply asking for a bigger processor is not a
    solution to a performance problem in an embedded system.

    Of course, the only thing this means, to us embedded software
    engineers, is that we can't use C++ in all applications.  I.e. I
    wouldn't use C++ in a Microchip PIC solution, even if I could find
    a compiler.  I believe someone else already said the same thing.
    I don't see how anyone could find this as any surprise.  But given
    a 32bit processor, are there any doubt that C++ can provide some
    benefit?  Even if you're only using the procedural programming
    paradigm?

There is also the issue of whether to use object oriented programming vs.
procedural programming.  But this is a separate debate, because there are
other languages besides C and C++ that supports these paradigms.  So I'll
leave that debate for another day.  ;-)

--jc
--
Jimen Ching (WH6BRR)       snipped-for-privacy@flex.com     snipped-for-privacy@uhm.ampr.org

Re: C++ in embedded systems
Quoted text here. Click to load it

Python, Modula-3, Ada, Scheme, etc.  All are vastly smaller
than C++ and support multiple paradigms (most at least three of
the following: functional, procedural, objects, generic).

--
Grant Edwards                   grante             Yow!  ... A housewife
                                  at               is wearing a polypyrene
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it
features
should
you
because

Well said. That's totally my viewpoint too.

Also I just found this on Jack Ganssle's (excellent) site at
http://www.ganssle.com/articles/momisms.htm :
Quoted text here. Click to load it
inheritance"; of those three, encapsulation is the easiest and most powerful
tool for building well-written, easy to understand code. It's equally
effective in assembly, C, or C++. Bind "methods" (code that accesses a
device or data structure) with the data itself. <<

... which I fully agree with.

Been thinking:
  - encapsulation: yeah, of course.
  - polymorphism: yeah, I do this too (in C/assembler)
  - inheritance: I don't do this at runtime, I do it by aggressive code
re-use (I *hate* writing the same code twice). Is this bad?

Quoted text here. Click to load it

Again, fully agreed.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: C++ in embedded systems
Quoted text here. Click to load it

No you don't have to.   But his point is (or should be) that there
are many non-OO aspects to C++.  Also, it's great that OOD et al
can apply to say C programming, but a significant point is that
C++ has features which map more closely to the above mentioned
paradigms being that the "modeling" notions are more directly
supported.   Ramification therefore include different techniques,
different idioms, different ways of thinking, etc.

Quoted text here. Click to load it

Indeed.


Not in and of itself.  Of course, if choosy == narrow-minded,
then one (not necessarily you) could be limiting yourself.
Of course too, on this same note, neither C nor C++ is the end
all to programming either.

Quoted text here. Click to load it

We are, unfortunately, creatures of habit, and crawling out
of something comfortable, even for our betterment, is often
not easy. :)  Enjoy it :)
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems


Quoted text here. Click to load it

Four ... you forgot functional.  However, C++ is primarily a
procedural language with support for OOP.   IMO, its support for both
functional and generic programming is poor and its support for
modularity is effectively nonexistent.

Many other languages support multiple paradigms: Modula 2 & 3, Oberon,
Ada, Lisp and Scheme, etc.  Some of them do it much better than C++.


Quoted text here. Click to load it

Your point about the standard covering more than the language is a
good one.  The coverage of the core language is only about 30 pages
and is comparable to other languages.

The C++ standard is enormous because it tried to address the
compatibility concerns of legacy C developers for every conceivable
platform whilst simultaneously trying to create a far more expressive
language with [at least partially] incompatible semantics.  If C++ had
taken a different direction, we might not be having these debates.


Quoted text here. Click to load it

I don't think people misunderstand this at all.  All of programming is
about defining the data to be manipulated and the functions which
manipulate it.   Object abstraction is not any different from type
abstraction.  Where the two methods differ is on the relationships of
types to one another.

Barring inheritence, there is a 1:1 relationship between the abstract
type model and the object model.    Including inheritence, there is
still a 1:1 relationship, but the abstract type model suffers due to
implementation complexity.  However, whether inheritence is even a
necessary component of OO is still an open debate.


Quoted text here. Click to load it

You can implement full C++ inheritence in C ... it is just very messy.
The first C++ compilers compiled into C as an intermediate step.
There are a number OO and functional languages that were originally
compiled into C before native compilers were written for them.


Quoted text here. Click to load it

Bloat is a valid (though manageable) criticism.  Most C++ compilers
link in all of a class's methods whether or not they are actually
referenced in the application.  Heavy use of templates creates many
nearly identical copies of code and interacts badly with the method
linkage problem because most templates are used to create new classes.
Not everybody knows that intrinsics are inlined.

Is it a programmer mistake?  I don't think so.  Obviously I believe
developer have a responsibility to read the compiler documentation,
but most of these issues are not discussed in documentation and have
been discovered empirically by people who, from necessity or
curiosity, disassembled their code to find out what was going on
inside.


George

Re: C++ in embedded systems


Quoted text here. Click to load it

Do you mean support or enforcement?  C++ supports these things, but does not
enforce them; enforcement is left to the programmer and the project's coding
standards.  C++ still retains C's flexibility, so, additionally, there are
some good middleware choices out there (CORBA, ACE, etc.) should you need to
extend these paradigms across a distributed system.

Quoted text here. Click to load it

I'll go with the notion that ADA offers better support than C++ for
object-oriented programming, but the thread started as a discussion of C
versus C++.

I'll also go with the notion that C++ is only as good as the compiler.  So
far, in my experience, only GCC and M$-Studio really meet the criteria of an
adequate compiler, with Studio in second place.  If you start on a C++
program with a marginal compiler, you will probably wind up finishing with a
C project and hating C++.




Re: C++ in embedded systems
On Sun, 17 Aug 2003 13:25:28 -0400, "Ian McBride"

Quoted text here. Click to load it

I said and meant "support" in the sense that C++ allows it to be done
with varying levels of difficulty.


Quoted text here. Click to load it

I was responding to the poster's missive to:

    "Name me another language that supports multiple paradigms and
     then we can compare."


Quoted text here. Click to load it

I agree completely about compiler quality being essential to the
experience.  I have used a few compilers that were so bad I would have
given up on C++ if they were my first experience with it.

VC vs GCC - I would qualify which versions of the compilers.  IMO VC6
is the equal of GCC 3.2.1 ... I haven't used any GCC later than that.
VC6 also offers, I think, slightly easier access to MMX and SSE for
Intel machines (which are what I care about).

George

Re: C++ in embedded systems

Quoted text here. Click to load it

This depends on what your definition of "functional" is.  Most people
hold it to be first class functions and some include higher order
functions.  Immutable data structures are not strictly necessary -
every recognized functional language allows destructive update in some
form.

C has first class functions (via function pointers) and C++ inherited
that from C.  That makes functional programming possible if not
necessarily easy.

You are correct that it is not recognized ... it is there nonetheless.


Quoted text here. Click to load it

You have a different definition of "support".   By my definition,
"support" for something in a language means that something can be
accomplished within the scope of the language's syntax and semantics.
To that end, assembler supports all possible paradigms - BASIC, for
example, does not.

I believe C++ was designed to add OO concepts to a procedural base
language.  Clearly it was not designed to *be* OO because objects are
not central to coding nor even necessary.  Writing purely OO code is
impossible in C++ because object support does not extend to the basic
data types.  However, writing purely procedural code is easy.

C++'s support for generics is no more than a kludge - a compiler
trick.  True generics allow functions to be written without regard to
data types.  That is impossible in C++.  Templates allow code to be
more easily "specialized" for a particular concrete type but they are
a far cry from generics.


Quoted text here. Click to load it

I mean design.

All the paradigms we are discussing are thought exercises.  OO centers
on abstracting the "world" in terms of actors and actions they
perform.  Functional and procedural models center on actions and the
objects to be acted on.  These models are not orthagonal, they are two
sides of the same coin.

I believe good designers bounce back and forth between these modes of
thinking constantly.  Our thought processes naturally deconstruct
problems in a certain way ... some problems are more actor oriented
and some are more action oriented.  Procedural thinking makes solving
an actor oriented problem clumsy - OO thinking does the same for an
action oriented problem.

Implementation issues are secondary to the thought process.  Any
Turing complete language can simulate any other (with varying degrees
of effort).  The extent to which any particular language helps in
implementing the program model is relevent only to expediency.  As all
program solutions involve some aspects from each of the models, the
choice of implementation language is less critical than the solution
itself.

I firmly believe the language wars arise, in part, because programmers
forget that their chosen language facilitates a model of thinking that
they find comfortable, and it is not the language they are defending
but their model of thinking.


Quoted text here. Click to load it

I wasn't referring to that aspect.  I was responding to your assertion
that C++ inheritence is impossible to achieve in C.  You said:

"Rudimentary inheritance can be achieved with nested structures in
C.  This is a mistake people often make with object oriented
programming.  First of all, nested structures in C is equivalent to
C++ data composition.  This is not inheritance.  Second, inheritance
involves more than just inheriting data variables, it also involves
inheriting interfaces.  You can't do this in C.  When people talk
about C++ inheritance, they are often talking about the latter. "

My response is: you absolutely CAN do this in C.  Full C++ inheritence
is possible in C as evidenced by the first C++ compilers which
compiled C++ code into C.  The result is very messy and, IMO,
unmaintainable, but it clearly demonstrates that C, in and of itself,
does support OO (at least to the same degree that C++ does).


Quoted text here. Click to load it

How is it a "mistake" to be ignorant of the cost of using a feature?
Particularly when the cost is either not known or not advertised.  As
I said before, most of these issues were found by frustrated
developers looking at the compiler's output.  The documentation for
your compiler rarely tells the gory details of the implementation of
language forms.

People who write code for GHz processors with virtual memory and RAM
to burn largely don't care about the overall efficiency of their
compiler or the relative efficiency of language forms (they may pay it
lip service, but in the end it doesn't affect their ability to write
the program).  I'm reading this thread in comp.arch.embedded where
most programmers do care.

George

Re: C++ in embedded systems
Quoted text here. Click to load it

Best post in this thread yet, IMO.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: C++ in embedded systems

Quoted text here. Click to load it

My definition of "first class functions" requires that the user be able to
create new functions at run time.  I can't see any reasonable way to
accomplish this in C using the supplied pointers to (const) functions.  If
you know of a way to do it, can you please share it with me?

Kelly



Re: C++ in embedded systems

Quoted text here. Click to load it

Hi Kelly,

My understanding of "first-class" is that a first class item can be
passed as a parameter, returned from a function and stored in a data
structure.  I've never heard that dynamic creation was a necessary
component.

No, C/C++ can't create functions but using function pointers you can
construct dynamic chainings of functions.  I wouldn't call it
"composition" (or anything close) but it suffices for a lot of uses.

George


Re: C++ in embedded systems

Quoted text here. Click to load it

Google found this:
http://puma.wellesley.edu/~cs251/spring02/first-class-functions.pdf
that lists the following conditions for "first class"-ness
 a) named by a variable
 b) passed as an argument
 c) returned as a result
 d) stored in a data structure
 e) created in any context

C has problems enough with arrays and structures let alone functions.  In
general, C forces one to be satisfied with pointers to non-trivial data
instead of the data itself.  Since I've been drinking the C Kool-Aid for
years now I understand that slinging pointers around is both what has to
happen deep down anyway on most CPUs and also enhances efficiency.  I've
been happy to keep arrays of function pointers to use as the basis for my
state machines.  It's just that C's support for functions is a whole lot
less featureful than almost any functional programming language.

The last item describes being able to create new functions within the scope
of another.  Pascal and its ilk do that quite nicely while C/C++ limits you
to global or file scoping.

Quoted text here. Click to load it

My attitude is that "sufficing for a lot of uses" lies somewhere down the
feature hierarchy from "first class".  I'm happy that C provides as much as
it does (it beats Fortran all to hell) but it still lacks the features I
enjoy from the functional language realm (ML, Haskell, Scheme).

Kelly



Re: C++ in embedded systems

Quoted text here. Click to load it

My education is obviously dated.  I took CS with Mitch Wand (EOPL) and
Rick Kelsey but it was more than a few years ago.  I don't recall that
creation context mattered - what was important ws that that the
whatsit be able to be passed around freely.

Nice to see Wellesley is teaching CS with Scheme instead of the
language du jour.


Quoted text here. Click to load it

No argument there 8-)


Quoted text here. Click to load it

True, but Pascal's nested functions have limited visibility - they are
not unlimited scope closures in the sense of Scheme et al.  


Quoted text here. Click to load it

Yeah, the only reason I care a wit about C++ is for business.  For my
own programming I wouldn't care if I never saw it again.


George

Re: C++ in embedded systems

Quoted text here. Click to load it


Stroustrup mentions the 'problem' of template code bloat in his
introductionary chapter on templates when he is explaining user defined
specialization. He then goes on to develop a example of how to avoid it.
Meyers mentions the 'problem' in item 42 of "Effective C++" and gives a
solution too. These are perhaps the two most read C++ books around.
On top of that the 'issue' is also mentioned again and again in language
wars when advocates of other languages compare their language against C++.
So this behavior is hardly unknown or unadvertized.

Quoted text here. Click to load it

The default template behavior is optimized for speed and you want it
optimized for size. Maybe implementers will provide templates with this
default behavior when C++ gets popular in the embedded world until then
just roll your own.


Quoted text here. Click to load it

--
Rob

Re: C++ in embedded systems
Quoted text here. Click to load it

I think it has more to do with what our definition of 'support' is, rather
than our definition of 'functional'.  I don't think we disagree on the
definition of functional programming.

Quoted text here. Click to load it

Yes, and I don't think we can convince each other to change our definitions.

Quoted text here. Click to load it

It depends on which object support you are refering to.  I must not be
using that particular support then.

Quoted text here. Click to load it

Stroustrup mentioned in his book that generic programming is only supported
statically, not at run-time.  I guess from that point of view, C++ can't
do full generic programming.  Of course C++ does static binding also.  This
is a theme in C++.  If your definition of these paradigms includes support
for dynamic use of these constructs, then C++ doesn't support any of
these paradigms.

Quoted text here. Click to load it

But you can't look at both sides of the coin at the same time.  This is
my point.  The models are views of the problem/solution.  Can you combine
the views?  Sure.  But is the resulting combined view the same as the
original views by themselves?  I don't think so.

It sounds like this is one of those differences in definition problems
again.  My definition of a paradigm is the philosophy behind a world view.
Your definition seems to imply that it is ok to throw in concepts from
other paradigms here and there, and it's still the same.  I consider the
result to be a different paradigm.

Quoted text here. Click to load it

What I was doing was extrapolating.

    Given C++ can be compiled into C; therefore, C can do anything
    C++ can do.

    Given any language can be compiled into assembly language;
    therefore, assembly language can do anything any language can do.

Again, this is a result of our differing definitions of 'support'.

Quoted text here. Click to load it

If a programmer was asked to produce an implementation, and the result
didn't meet the requirements because of his ignorance of a feature, you
don't consider this a mistake on the part of the programmer?  Call it
whatever you want.  It's not the fault of the language or the tool, in
my opinion.

Quoted text here. Click to load it

Are you making an assumption that I'm a desktop programmer?  I've been
an embedded software engineer for 7 years, and spend all of that time
designing and implementing software to be efficient in both memory and
CPU usage.

Having said that, I don't totally agree with you about the desktop
programmers.  I agree that there are still many programmers that don't
care about efficiency.  But free software projects like GNOME and KDE
are learning the hard way that efficiency can't be ignored.  Even GCC,
our favorite compiler, is feeling the heat.  Just take a look at the
number of complaints about later versions of GCC on their mailing list
concerning compile times.

Of course, this is all off topic.  As I've said in my original response,
the bloat and performance problems are a myth.  I believe Stroustrup
himself responded with a pointer to a paper about the subject.

--jc
--
Jimen Ching (WH6BRR)       snipped-for-privacy@flex.com     snipped-for-privacy@uhm.ampr.org

Re: C++ in embedded systems

Quoted text here. Click to load it

I'm referring to being able to derive from and change the behavior of
the "basic" types (int,float, etc.).  This is possible in, e.g.,
Smalltallk because *everything* is an object.

C++ makes a clear distinction between them.  So does Java for that
matter, but at least Java provides [separate] object versions of the
basic types.



Quoted text here. Click to load it

Sure you can ...  just hold it at the end of your nose 8-)


Quoted text here. Click to load it

You clipped a lot of what I said.  As I stated before, I believe a
good designer naturally uses both models because our thinking
processes naturally do.  Trying to rigorously apply just one design
method is, IMO, a mistake which leads to convoluted solutions and
therefore directly to buggy software.   I believe the problem should
be solved in the most natural way of thinking about it - sometimes
that is OO and sometimes it is functional.


Quoted text here. Click to load it

My definition of support is that the language can express the
abstraction within its syntax and using its semantics.  BASIC's
constructs cannot model OO abstractions ... C's can.  Assembler can
model any abstraction and is not relevent to this discussion.


Quoted text here. Click to load it

I will agree that the problem is a confluence, but I don't believe the
statement that it is solely a mistake of the programmer.  In order to
be a "mistake", the programmer must have been aware of the problem and
still chosen to use the problematic feature.



Quoted text here. Click to load it

I'm had no preconceptions about what you do.  I also use C++, instead
of C or asm, for embedded programming whenever possible.  But I
recognize its limitations and don't try to hammer screws with it.  I
also recognize the difference between language and implementation,
however the implementation is what ultimately matters.


Quoted text here. Click to load it

I'm a big fan of interpreted (or incrementally compiled) languages
that can be compiled to produce the final application.   Development
of complicated code is, IMO, made much easier when you can test your
idea immediately upon coding it.  Having to wait out the typical
compile and link cycle to test something too easily breaks the train
of thought (the phone rings, someone knocks on the door, etc.).
Embedded programming adds "download to target/simulator" and makes the
process even longer.  I believe writing correct software is easier
when you can focus on solving one problem at a time rather than trying
to cover several (or several dozen) issues in a single build because
the turnaround on a new build is so long.

I don't get to actually write code that way ... but I can dream.

I am concerned by long compile times (which seem to get longer with
every new compiler release).   But in the end I am far more concerned
about the performance of the resulting executable than I am about how
long it took to produce it.  To that end, I want all the analysis and
optimization the compiler can deliver.


Quoted text here. Click to load it

The topic was "C++ in embedded systems".

Who mentioned performance problems?  Anyway I agree that C++ has
equivalent performance to C for most programs.  I also agree that a
problem that is a good fit to the OO model can have a smaller code
footprint using C++ than using C.  However I think this saving is
partly illusory - the runtime data footprint is larger with C++ and I
believe equivalent programs use approximately the same resources in
total.  YMMV.


George

Site Timeline