C++ in embedded systems - Page 4

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
moment.
far
can

The global optimizaer is global for the module as you said, and is part of
almost all current compilers. Link-time code-generation (VC term) is another
thing and is part of VC since 7.0, I think. It's definitely part of 7.1.

Quoted text here. Click to load it

In theory yes. In practice, I haven't heard of anyone doing such things in
the FE. But maybe I'm wrong.

Regards,
Andras Tantos



Re: C++ in embedded systems
Hi!

Quoted text here. Click to load it

Yes it's academic. But I was interested so I've talked to a couple of people
and flipped through the C++ standard and found this:

5.2.2 - Function call [expr.call]
....
-3- The type of the function call expression is the return type of the
statically chosen function (i.e., ignoring the virtual keyword), even
^^^^^^^^^^^^^^^^^^^^^^^^^^
if the type of the function actually called is different. This type
shall be a complete object type, a reference type or the type void.

From this I would conclude that overloaded function resolution happens at
compile-time, statically.

Regards,
Andras Tantos



Re: C++ in embedded systems


[8<8<8<]
Quoted text here. Click to load it

Could you be more specific about which compilers you have observed what.

Quoted text here. Click to load it

The book
   Inside the C++ Object Model
   Stanley B. Lippman
   ISBN 0-201-83454-5
describes in details what (pseduo C) code a C++ compiler might generate for
various constructs.
Although the book is prestandard (1996) it contains a lot of usefull
information.

Also have a look at
   Technical Report on C++ Performance
   http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2002/n1396.pdf
which is written by the C++ Standard committee
<quote>
  * to give the reader a model of time and space overheads implied by use of
various C++ language and library features,
  * to debunk widespread myths about performance problems,
  * to present techniques for use of C++ in applications where performance
matters, and
  * to present techniques for implementing C++ Standard language and
Standard library facilities to yield efficient code
</quote>

Quoted text here. Click to load it

Could you give a specific example ?

I think that we need to be carefull about what we are talking about here.
We can be talking about:
  1. Function templates
  2. Non-virtual member functions of class templates
  3. Virtual member functions of class templates

1.
Function templates like
  template <T>  void foo(const T* t);
are only implicit instantiated if they are used.
Thus for Standard compliant C++ compilers, it's a non issue.
It's even hard to image how it could be an issue for non compliant
compilers.

2.
Non-virtual member functions of class templates like
  template <T>
  class bar
  {
  void  foo(const T* t);
  };
are only implicit instantiated if they are used.
In fact the compiler are not even _allowed_ to instantiate the non-virtual
member functions if they are not used.
It is not requiered that the member functions is compileable at all, if it
is not used like shown below
<C++ code>
#include <iostream>

template <typename T>
class bar
{
public:
   void   foo(const T* t);
};

template <typename T>
void bar<T>::foo(const T* t)
{
   const char* c = t;
   while (c && *c)
      std::cout << *c++;
   std::cout << std::endl;
}


int main()
{
   bar<char>   bc;         // valid
   bc.foo("hello world");  // valid
   bar<float>  bf;         // valid
   float       f = 0;
   bf.foo(&f);                // error bar<float>::foo not compileable
}
</C++ code>

Thus for Standard compliant C++ compilers it's a non issue.
Non compliant compilers might instantiate every member function for class
template for every type that class template is used.
However it is long time ago (mid 90's) I saw that the last time.

See 14.7.1-9 in the C++ Standard for the details.

3.
Virtual member functions of class templates are likely (allowed, but not
required) to be instantiated and linked, even if they are not called.
The same is the case for virtual functions for classes that are not class
templates.
Thus it's an attribute of the virtual function mechanism and not the
template mechanism.

Quoted text here. Click to load it

Pretty good I would expect.
Many embedded C++ compilers (like Green Hills, Microtec, DIAB) are based on
the EDG front-end (http://www.edg.com/customers.html ), which, for at least
the last decade, has only implicit instantiated member functions of class
templates which are required to exist.

If you are using a C++ compiler, which does not have the behaviour as
required by the C++ Standard and commonly implimented by a lot of compilers
you should either complain to the vendor or change compiler vendor.

Quoted text here. Click to load it

Which x86 compilers are you refering to ?
On the MS-Windows platform the 2 most used compilers are probably Microsoft
C++ and Borland C++.
Since approximate the middle of the 90's those compilers have not
instantiated not used, non-virtual member functions.
And note that these compilers where behind the state-of-art in this respect
at that time.

Quoted text here. Click to load it

A lot I would expect.
We have been using partial template specialization for embedded projects for
more than 5 years using a compiler based on a rather older EDG frontend.

Quoted text here. Click to load it

No.
The combination of templates and inline functions is a very efficient way of
writing high level, high performance code - also for embedded systems.
I've been doing that for many years.

There are many libraries which uses compile-time polymophism (as opposed to
run-time polymophism like virtual functions) to provide both a higher
abstaction level and performance at the same level as C or better.
The C++ Standard library function std::sort is a classic, simple example but
there are many others.

Quoted text here. Click to load it

No - understand the consequences of using exceptions, before deciding.
Both in terms of performance and in terms of programming style.
You should know how to write exception safe code before using exceptions in
C++.
It is well understood and well described and has been so for years.
See
  The C++ Programming Language, Special Edition
  Bjarne Stroustrup
  ISBN 0-201-70073-5
appendix E (that appendix can be downloaded from Bjarne Stroustrup's
homepage http://www.research.att.com/~bs /).
And
  Exceptional C++
  Herb Sutter
  ISBN 0-201-61562-2
and
  More Exceptional C++
  Herb Sutter
  ISBN 0-201-70434-X

Exception comes at a price - even if no exceptions are ever thrown.
But so does every error handling strategy.
Even ignoring error handling comes at at price :-)

Quoted text here. Click to load it

It is possible to compare error handling strategies with respect to various
parameters like
  * code size
  * execution performance when no error happens
  * execution performance when an error happens
  * amount of effort requiered by the programmer
  * how error prone are the error handling strategies
However it is not resonable to compare a program, which handles error
conditions correct with a program which does not handle error conditions.

Let's be a bit more concrete and compare an example which rely on
constructor/destructor and exeptions with an example which rely on error
codes and explicit initialization and clean up and error codes.
Let's take an example which opens 3 files and processes the files - both
examples are C++ but the style is different:
<C++ code>
void foo_throw();
int foo_code();

void bar_1(const char* f1, const char* f2, const char* f3)
{
   ifstream    is1(f1);
   if(!is1)
      throw runtime_error("unable to open first file");
   foo_throw();   // might throw

   ifstream    is2(f2);
   if(!is2)
      throw runtime_error("unable to open second file");
   foo_throw();   // might throw

   ifstream    is3(f3);
   if(!is3)
      throw runtime_error("unable to open third file");
   foo_throw();
}

int bar_2(const char* f1, const char* f2, const char* f3)
{
   FILE*    is1 = fopen(f1, "rt");
   if(!is1) return 1;
   int      result = foo_code();
   if(!result)    {
      fclose(is1);
      return result;
   }

   FILE*    is2 = fopen(f2, "rt");
   if(!is2) {
      fclose(is1);
      return 1;
   }
   result = foo_code();
   if(!result)   {
      fclose(is2);
      fclose(is1);
      return result;
   }

   FILE*    is3 = fopen(f3, "rt");
   if(!is3) {
      fclose(is2);
      fclose(is1);
      return 1;
   }
   result = foo_code();
   fclose(is3);
   fclose(is2);
   fclose(is1);
   return result;
}
</C++ code>

In my opinion "bar_1" is far simpler than "bar_2".
The use of constructors/destructors _garanties_ that there can't be any
resource leaks.
The use of exceptions means that error handling doesn't clutter the normal
flow and there is no way that we can forget to test for an error.

[8<8<8<]
Quoted text here. Click to load it

It depends ...
What's the declaration of "foo" ?
   1.  void foo();
   2.  void foo() throw ();
   3.  extern "C" void foo();

The first declaration says that "foo" might throw anything, thus the
compiler has to deal with that in some way.
For the second and third declaration the compiler knows that there is no way
an exception can propagate out of the function, thus it doesn't have to
generate anything extra.

[8<8<8<]
Quoted text here. Click to load it

I don't quite understand what you mean.

Of course the program flow is different if an error occurs, if the program
is supposed to behave correctly.
It doesn't matter whether you use constructor/destructor or not.
It doesn't matter whether you use exceptions or not.

Quoted text here. Click to load it

No.
"foo" gets coded exactly the same way - it's the very same function that is
called.

With modern high quality compilers the call to "foo" is not coded
differently for the first and the second call.
Neither calls are augmented with error handling code - there is only the
"call" assembler instruction. The exception handling code is only executed
if an exception is actually thrown - there isn't even a test to check if an
excetion is thrown.
I have verified that with Intel C++ V7.1 and Microsoft Visual C++ .NET 2003
on MS-Windows and g++ V3.2 on Linux.
The compilers for MS-Windows are of course are not specificly for the
embedded market, but there is no reason why embedded compilers shouldn't be
able to do the same thing.
The Intel compiler is based on the EDG front-end - just like several C++
compilers for the embedded market. It is likely that the exception handling
code is handled by the front-end.

The program behaves differently depending on whether an error condition
occurred.
But that's not a matter of exceptions/not exception - it's a matter of
program correctness.

Quoted text here. Click to load it

Who would expect that the the two calls take the same time and require the
same resources if the first call succeed and the second call fails ?

If both calls to "foo" succeed it is fully possible and not unlikely that
the two calls would take the same time and require the same resources.
In fact they do with the compilers mentioned above.

See "Technical Report on C++ Performance" chapter 2.4 for at detailed
description the "code" approach and the "table" approach to exception
handling.

If there is no way that "foo" can fail, you can tell the C++ compiler that
in the function declaration with an empty throw specification.

Quoted text here. Click to load it

Again, if there is no way "foreign" can fail, we can specify that by:
void foreign() throw();

Quoted text here. Click to load it

Sure.
But T::~T is going to be executed in any case, simply because "s" has been
constructed.

Quoted text here. Click to load it

Why not tell the compiler what he/she knows with an empty throw
specification ?

Quoted text here. Click to load it

Constructors/destructors are a huge help.
It makes it far easier to write correct programs.


Quoted text here. Click to load it

Yes.
That means that
  * You don't have to clutter your normal program flow with error handling
code
  * There is no way you can forget to handle an out-of-memory situation

Quoted text here. Click to load it

For references - not for pointers.

Quoted text here. Click to load it

It doesn't have to be that way.
See "Technical Report on C++ Performance".

If no error occurs you will have error handling code, which is never
executed.
The same is the case if functions return error code:
   if(!foo())  {
     // error handling code goes here
     return;
   }


[8<8<8<]
Quoted text here. Click to load it

No.
They make it far easier to establish invarians in constructor and ensure
correct cleanup in destructors.

[8<8<8<]
Quoted text here. Click to load it

You can you the "explicit" keyword in C++ to prevent implicit conversions.

[8<8<8<]
Quoted text here. Click to load it

You can most definitely write code in C++ which behaves unexpected.
But why wouldn't you always catch exception objects by const reference ?
  try  {
     // ...
  }
  catch(const  std::exception& x) {
    // ...
  }

[8<8<8<]
Quoted text here. Click to load it

That not very accurate.
It is easiest to use smart pointers if the member sub-object are dynamic
allocated.
You can also write try/catch clauses in the initialiser list.
Often member object are simply members, and there is _nothing_ to worry
about:

class unconstructable
{
public:
    unconstructable()
      {   throw 1;  }
};

class foo
{
public:
   foo(const char* text_1, const char* text_2) :
    s1(text_1), s2(text_2) {}
private:
   std::string    s1;
   std::string    s2;
   unconstructable halt;
};

In this example "s1" and "s2" will (normally) be fully constructed before it
is attempted to construct "halt" which will always fail.
There is _no_ need for smart pointers or manual intervention to ensure that
"s1" and "s2" are properly destructed and resources are released.

Quoted text here. Click to load it

Often you dont' have to write anything - as shown above.
It's a simple matter of using an effecient coding style.

When writing C++ you must deal with C++ semantics.
Does that suprise you ?

[8<8<8<]
Quoted text here. Click to load it

Of course you can write sub-optimal programs in C++ - the language doesn't
prevent that.
But why should we ?
You can simply write:
  A  rA(const A& p) { return p;  }
to prevent the compiler from creating a copy when parsing the argument p to
the functions.
A lot of compilers will do return value optimization.

[8<8<8<]
Quoted text here. Click to load it

It sounds like FUD to me.
A lot of people that I know has at least an understanding of the principles
of what code the compiler might generate.
Of course there are a lot more people who doesn't. My mother doesn't know -
but she doesn't program embedded devices in C++, so it doesn't matter.
It doesn't take a genious to understand the principles of what code the
compiler might generate.
It does however take education - but the sources are available.

Kind regards

Mogens Hansen








Re: C++ in embedded systems

Quoted text here. Click to load it

[8<8<8<]
Quoted text here. Click to load it
for

Sorry.
I was thinking of full member specialization.

But still I would expect several C++ compilers for the embedded market to
support partial template specialization.

Kind regards

Mogens Hansen



Re: C++ in embedded systems

Quoted text here. Click to load it

Agreed.


That's definitely possible to predict what code a C++ compiler might
generate from various construct.
I've been doing that for more than 12 years - approximate half of that time
developing embedded systems.
The embedded systems where mostly with performance compareable to a 16 Mhz
80386, 2 MByte ROM, 2 MByte RAM.

Quoted text here. Click to load it

Of course there are "some embedded environments" where C++ is inappropriate.
The same is true for all languages.
It can be because the target machine have very limited resources and _very_
tight control is requiered.
It can also be because of some company policy which specifies the use of
another language.

The C++ language can be understood and used effectively in embedded
environments.
It takes skills and care to write high performance code in any language.
Educations and understanding is a prerequisite for using C++ effectively,
but there are a lot of sources to learn from.

Kind regards

Mogens Hansen



Re: C++ in embedded systems
snipped-for-privacy@visi.com (Grant Edwards) wrote in

Quoted text here. Click to load it

Which, in essence, is exactly what I said in the paragraph
preceding the one you quoted, and which you conveniently snipped.

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems
snipped-for-privacy@yahoo.com (Mad@Spammers) wrote in message
Quoted text here. Click to load it

You should check out the Rationale for Embedded C++.  It gives a good
overview of which standard C++ features were left out and why.

http://www.caravan.net/ec2plus/rationale.html

I think they drew a pretty good line about which features are and
aren't useful for embedded systems.  Although I don't understand why
they felt it was necessary to eliminate wchar_t.

Re: C++ in embedded systems

Quoted text here. Click to load it

EC++ might be correct to leave out RTTI and C++ EH, but disagree with some
of the other decisions. The assumption seems to be that embedded developers
are not as competent as desktop developers and that embedded software is
much simpler (I'm thinking of mutable ["it might confuse them"] and
namespace [embedded software isn't big enough]).



Re: C++ in embedded systems

Quoted text here. Click to load it

eC++ dumbs down the language under the pretense that embedded programmers
are too stupid to properly use the deleted features.  In reality, I think
eC++ is a cop-out by compiler vendors who can't keep up with GNU.  They want
to change the rules for the sake of their marketing departments.




Re: C++ in embedded systems
Hi Ian,

Quoted text here. Click to load it

I tend to agree - I also think that at times C++ gets bad press merely
because compiler optimizations are not at the same level of maturity as
many C compilers.

FWIW given the current work on g++ and gcc and the huge steps forward
that are being made in optimizations (should appear in gcc-3.5) then I
think the bar is going to be raised significantly.

For embedded systems use I believe the interprocedural optimizations and
the new tree-SSA optimizers will start to be available will allow a
level of expressiveness that has just not been possible to date.

This probably means that right now C++ may not be the best of choices at
all times, but I suspect that that view will start to change.

I believe the most important contribution that such optimizations will
give will be that they will automatically "specialize" generic code in
many cases.  This will allow embedded developers to focus on good
algorithms and good design and leave the tools to generate optimal code
(gcc never ceases to surprise me by some of the clever tricks it already
does at a high-level, although of course there's always room for
improvement ;-)).

I would note that, yes, C++ may not prove to be a particularly good fit
for something like a 16-series PIC or an AVR tiny, but then there are
many things I can't do in C for those targets either (recursion, heavy
use of strings, file I/O etc).  As with all things developers need to be
aware of the capabilities of the tools they are using and use them
appropriately.  For some reason software engineers seem to be almost
unique in their love of "one solution fits all" approaches - if I want
to make a uniform wooden candlestick I'd rather use a lathe, but it
seems that all too many software developers would rather keep using the
mallet and chisel that they'd used for the last job they did :-(

As with all things, using a new tool effectively requires understanding
what it can and can't do, and when it works best.  With software
engineering this means *really* getting to grips with many development
concepts and many programming languages.  The singular characteristic I
find with really talented embedded software engineers is that they all
have a very great breadth of knowledge of such things - they also all
make time to learn new things, even if only to conclude that some of
those things may not help as much as they first hoped :-)


Regards,
Dave


Re: C++ in embedded systems
snipped-for-privacy@aol.com (Dingo) wrote in

Quoted text here. Click to load it

Personally, I subscribe to the view that EC++ was concocted by
compiler vendors in order to create a market for their non-Standard-
compliant C++ compilers.

I find many aspects of the rationale downright insulting, making
direct or indirect references to embedded system developers' supposed
limited ability to comprehend C++.

The removal of templates, exceptions, and RTTI is arguably justified
on the grounds of efficiency although, as has been pointed-out elsewhere
in this thread, any half-decent C++ compiler will allow the user to
disable those anyway.

On the other hand, perhaps someone can explain why "mutable", namespaces,
and the C++-style casts were removed, if not to make the compiler-
writers' lives easier.

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems

Quoted text here. Click to load it

Yes, my point exactly; that's what I meant by "to make compiler-
writers' lives easier." But that is not an argument invoked by
the EC++ rationale.

There are many other things that could be removed from C++ that
would have a much greater impact. What a coincidence that the
things that were removed are largely things that were late additions
to the C++ Standard and that therefore would have required extra
effort to be supported by pre-Standard compilers.

I don't care if vendors want to subset C++ out of desire to
sell their sub-Standard compilers to developers. I _do_ care when
they spread FUD about C++ in order to do it. These deletions in
no way make EC++ better able to "fulfill the particular requirements of
embedded systems designs" than full C++.

Quoted text here. Click to load it

"mutable" is also indispensible in certain circumstances to allow
for const objects, and const objects are very useful in leveraging
the C++ type system to assist in making code more reliable.

Quoted text here. Click to load it

static_cast, const_cast, and reinterpret_cast have nothing to do with
RTTI. Only dynamic_cast is related to RTTI.

On the other hand, static_cast and const_cast do make a program more
reliable and more maintainable by working within the compiler's type
system, instead of bypassing it, as C-style casts do.

Quoted text here. Click to load it

Both C and C++ define numerous different symbol scopes, so I have a
really hard time believing that namespaces will slow anything down
significantly.

Quoted text here. Click to load it

Visual C++, for one, allowed this long before EC++ came along, and
I'm sure that others did too.

Quoted text here. Click to load it

How does EC++ make this easier than a simple line of text in the
description of the library that would state "does not use exceptions
or templates"?

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems

Quoted text here. Click to load it

...And/or RTTI.  You were completely write about all C++ style casts.
Only dynamic cast is requiring RTTI support.  I believe GCC will
automatically warn about this if -fno-rtti is used.  I guess this
should be implicit.

I think that having the Standard does help to quantify what library
facilities are used.  Does the average programmer have time to
quantify every aspect of the language.  Getting the compiler options
correct with a binary only distribution can be problematic.

I would be much more likely to buy/use a library that was Embedded
'C++' compatible.  Even after reading the working groups paper on C++
performance, I think that exceptions are too expensive for my embedded
devices with the compiler that is bundled with the OS.  In fact I
believe that stack tracing and tables will alway be more expensive in
code space than letting a watch dog go.  In the WG21 paper sighted,
the exit/reset on error conditions didn't seem to be compared to EH
overhead.  Exit/reset on error are often used for simplicity and
safety in embedded systems... at least that has been my experience,
but maybe I am some sort of horrible barbarian.

I do think that at some point linkers and compilers will become mature
enough ( and host computers will be fast enough) that templates will
be useable and beneficial in the embedded space.  But I have never
seen a compiler that handle templates well enough for my needs.

Of course you can explicitly spell out every condition that a library
adheres too, instead of just saying "Embedded C++ compliant".  Just
like you can do everything in assembly that you can do in C++.

fwiw,
Bill Pringlemeir.

--
If I gave a damn, you'd be the first person I'd give it to.

Re: C++ in embedded systems

Quoted text here. Click to load it

Namespaces are just a formal way of specifying how to decorate 3rd party
API's with a vendor's name to avoid collisions. Removing them causes
additional code clutter as one is forced to decorate every point of usage
(eg. "vendor27_do_something()"). (With namespaces, one uses a using
statement at the top of a block to identify which vendor's API's are in
force for that block.)

If you use no 3rd party code (including libraries developed by other teams
within your organization), namespaces are admittedly superfluous.

--
Kenneth Porter
http://www.sewingwitch.com/ken /

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

I happen to disagree; that line isn't clearly and cleanly drawn (or
could be in general). That "rationale" is pretty old and concerns
other than safety in embedded systems (such as the availability of
in-house-built C++ compilers) influenced the decisions.

For a different and somewhat contrary view, have a look at the ISO C++
standards committees TR on peformance issues:
http://www.research.att.com/~bs/performanceTR.pdf

  - Bjarne Stroustrup, http://www.research.att.com/~bs

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

Strange statement, which of course I totally disagree with ;). I do OO in C
and assembler all the time. With real projects. I have no desire to use C++.
OO is a design issue, not a coding issue. (C++ is not just a coding
language - it could be considered a very much higher-level language than
C++, and indeed that's part of my problem with it.)

However I guess a) you would imply that I'm not using OO "well" and b) it
depends on exactly how you define OO. I use OO in the sense of
encapsulation, data-hiding, polymorphism, inheritance etc. I don't use all
the other gubbins that tends to get associated with it e.g. operator
overloading, multiple inheritance, etc. I use the features that benefit
clarity and maintainability, and avoid those that adversely affect them.

Here's briefly/roughly what I do:
  - one class per module (usually defined as a private struct of member
variables and function pointers)
  - no project-global variables (ony the interface member functions are
public)
  - polymorphism involves passing one more variable (which effectively is
the index for a state machine)

Not hard.

Quoted text here. Click to load it

The need for discipline is true of all design, surely? Once mastered, why
can't it be sustained?

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



Re: C++ in embedded systems


Quoted text here. Click to load it

C++ is often criticized because it is bloated and too complex.  The K&R
book, complete with tutorial, is about 200 pages.  A good C++ book is
well over 1,000.  How can anyone actually master a language like that?

C++ started out with a good idea and then tried to become all things to
all programmers. Now, does that mean that we should dump C++?  Think
about the logical progression of languages.  In the beginning we had
data items, then arrays of like-kind data items, then structures of data
items of differing kinds and sizes.  The next step is simply a structure
that not only contains the data items, but also the functions that
operate on that data.  We call that a class.

The class should be used for the same reasons that you would use a
structure; it clumps things together.  Is it a necessity? No; you could
clump things together using separate files.  An example of this in C is
FILE.  It is an I/O structure with all of the functions, such as fopen,
needed to operate on the data. Although using classes is not a
necessity, neither is the use of a structure.  Try writing a C program
without using a structure.

Now about your issue of the difficulty of optimizing after the fact.
Tony Hoare stated, and restated by Donald Knuth: "Premature optimization
is the root of all evil".  The original quote was, "We should forget
about small efficiencies, say about 97% of the time: premature
optimization is the root of all evil."   Why optimize until you know
where the bottle neck is?

I came from the era when all embedded code was written in assembly;
processors just weren't fast enough.  Now the processors are faster and
the compilers are better.  I now write in C, C++ and assembly.

The most important thing to remember is that we write programs to make
money.  A programmer who doesn't use the tools of the time will take
longer to market and loose revenue.  Just write good code, know when to
use C, C++, assembly,  and know when to use which tools.  You don't want
to become one of today's programmers who need a PC with the speed and
horse-power of yesterday's Cray Super computer just to run a simple word
processor.

Marty Pautz


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

   The most important optimization is done during DESIGN!  Proper choice
of algorithms is BY FAR more important than bit twiddling.

Quoted text here. Click to load it

I have also been in the business for a while and use many languages
(hopefully choosing the right one) and love BOTH C++ and Forth.  Properly
written C++ is more efficient than C, and Forth can create the smallest
ROM image.  It depends on what you are trying to optimize!

Todd


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

Replacing a few words in your statement, we have: "doing hi-level
programming in a non-hi-level language demands ..."  This applies
to using assembly, and equally to using C.

The better programmers in both languages impose exactly that sort
of discipline on themselves, and get very irritated at languages
that do not allow them to ignore those disciplines when needed.
Unfortunately many such programmers have a poor perception of
'when needed' and thus leave many incipient bugs and insecurities.

The C programmers attitude to Pascal, and the inverse, are
examples.  The languages are highly similar, with very similar end
capabilities.  Escape hatches in Pascal need to be carefully
thought out to preserve reliability.  External routines, file
drivers, etc. come to mind.  A system which allows controlled
intermixing is Ada.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
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

Modula-3 is another good example.

--
Grant Edwards                   grante             Yow!  My uncle Murray
                                  at               conquered Egypt in 53
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline