C++ STL in embedded systems

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

Translate This Thread From English to

Threaded View
Are there any restrictions/problems for use of  C++ STL in development
in embedded systems?
In particular:
* Does STL require too much space/memory?
* Is 'implementation of STL algorithms/methods' reenterable/reentrant?
* What is the cost to provide  continuity of vectors in memory?
Any other problems?

--
 Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ STL in embedded systems
Quoted text here. Click to load it

Perhaps.  That depends upon the implementation and
the platform (and perhaps other criteria, such as
the nature of your application).

Quoted text here. Click to load it

How much is too much?  Also note that each specific
standard library implementation may consume different
amounts of resources.

Quoted text here. Click to load it

That depends upon the implementation.

Quoted text here. Click to load it

Not sure what you mean my 'continuity'.  However, the elements
of a std::vector object are required to be contiguous in memory.

Quoted text here. Click to load it

Perhaps.

-Mike



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

You might want to think about exception handling.

Quoted text here. Click to load it

for a small system, yes. But if you need the functionality, it's probably
better than writing it yourself.

Quoted text here. Click to load it

I ran into trouble some years back with microsoft's VC++ implementation
not being reentrant. <string> reference counts were seeing race
conditions. STLPort seemed to fix the problem. But replacing shared
<string> with (const char*) really helped.




--
    mac the naf

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

Good point. On some of my embedded projects, the compiler didn't
support exceptions at all, and so, neither did the STL. Of course, such
an implementation is not fully conformant to the standard, but it was
still very useful. And some parts of the STL don't throw exceptions
anyway (e.g., std::auto_ptr, many algorithms).

Cheers! --M


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


I'm with the Embedded C++ folks <http://www.caravan.net/ec2plus/ on this.
I think that the minimum "contract" for a method call is that it return.
But your needs may differ.

As to conformance, I don't know that I've run across a fully conformant
compiler/runtime yet. As implementations like GCC approach conformance,
their libraries have to keep changing.

The result seems to be that C++ has become unstable. You can't link
against a library unless you're using the same compiler version. It's best
if you have all the libraries in source.
--
    mac the naf

Re: C++ STL in embedded systems

Quoted text here. Click to load it

Whaddayamean, "become"?  From where I sit, C++ feels like it has been
a moving target ever since its invention.  Its defining standards
change faster than the implementations.  Each time the implementors
finally seem to be catching up, the goal is moved.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

It depends entirely on the needs of the particular embedded systems.
Some of today's embedded systems use yesterday's desktop processors,
and consequently, they often have more memory available, have compiler
and standard library with relatively good conformance to the C++03
Standard, and are less susceptible to the kind of problems that the OP
was concerned about.

On the other hand, I have successfully used a subset of the STL
(including std::vector) on an embedded system that has stricter
requirements than "high-end" embedded applications. The compiler for
that system doesn't support exceptions or some other C++ features
(yet), but otherwise, it is fairly good as far as conformance.

Quoted text here. Click to load it

No fully conformant compiler cum library exists, though some are close
and are available on a wide variety of platforms (GNU, Comeau, etc.).
But things are getting better IMHO, and many of the remaining
non-conformancies are in areas of the Standard that are not as useful
as they first appeared (e.g., the export keyword).

In any case, I write object-oriented C++ code that uses the STL that is
buildable on several different embedded platforms with different
compilers, and I use a commercial lint tool that helps maximize the
portability (as well as check for errors). The bottom line for me is
that, while C++ compilers and libraries are not fully conformant, they
are conformant enough for my needs (and I suspect for many other
programmers' needs).

Quoted text here. Click to load it

Can you give an example? The library implementations might be refined
or tweaked behind the scenes, but the interfaces should generally be
stable.

Quoted text here. Click to load it

I'm not sure what you mean here. I don't think you mean that different
compilers generate different object file formats or that they use
different calling conventions since these problems would apply equally
to any language, but are you referring to the fact that, e.g., a
library function might throw an exception but your compiler doesn't
support exceptions? Please clarify.

Cheers! --M


Re: C++ STL in embedded systems

Quoted text here. Click to load it

Uh, the EDG front end has been fully compliant for several years
now, and the Dinkumware C/C++ library has been for even longer.
Since we have a number of OEM customers in common, integrated
fully conforming C++ compilers do exist. You can also paste together
your own by licensing Comeau C++ (which uses EDG) and our library.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



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

I stand corrected.

Cheers! --M


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



One thing to note here, you might not be able to use a particular
standard library implementation, but you can certainly use the STL
concepts.  As long as you have some class that models the concepts in
STL, you should be able to use many of the standard library algorithms
without any problems.

I think the major overhead comes from iostreams, locales etc.

Hope this helps,
-shez-


Re: C++ STL in embedded systems
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Vinokur wrote:
Quoted text here. Click to load it
In the any category, the main criticism for using a straight C++ lib,
let alone STL, is that the stock new() is non-deterministic. I hear tho
that there are certain embedded C++ tool chains which might have some
methods of getting around this. At least, in the early 90's I remember
Chrysler getting into one for one of its auto controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDu0FwpxCQXwV2bJARAsm+AJ0c3bCEdHDsiKzEhM6AEk3PIBYtvACeNRTa
jB2W3uidBsbZsnsViEz7eB0=
=bBVe
-----END PGP SIGNATURE-----

Re: C++ STL in embedded systems
On 3 Jan 2006 10:47:05 -0800, "Alex Vinokur"
Quoted text here. Click to load it

Hey look what I just found, from their website:

The Dinkum EC++ Library as specified by the Embedded C++ Technical
Committee. (See the Dinkum EC++ Library.) This is far and away the
most widely used EC++ library in the embedded programming community.

http://www.dinkumware.com/libdual_vc.html

Good Luck.

Not all those who wander are lost. - J.R.R. Tolkien

Re: C++ STL in embedded systems

Quoted text here. Click to load it

Right, and if you really want:

-- STL

-- namespaces

-- exceptions

you also get our Abridged library, in the same package, that
extends EC++ with each of these three optional features.
Many embedded C++ compilers ship with this library.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Re: C++ STL in embedded systems

[snip]
Quoted text here. Click to load it
[snip]

Does 'Green Hills C++ Compiler' use your Abridged library?

Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978.html
     http://sourceforge.net/users/alexvn


Re: C++ STL in embedded systems

Quoted text here. Click to load it

Yes. They also ship our full C++ library as well.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Re: C++ STL in embedded systems

[snip]
Quoted text here. Click to load it
[snip]

Is 'implementation of STL algorithms/methods in Extended Embedded C++'
reenterable/reentrant?

Thanks.

Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978


Re: C++ STL in embedded systems

Quoted text here. Click to load it

Yes.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Re: C++ STL in embedded systems

[snip]
Quoted text here. Click to load it
[snip]

Is 'implementation of STL algorithms/methods in Extended Embedded C++'
reenterable/reentrant?

Thanks.

Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978


Re: C++ STL in embedded systems

|| Many embedded C++ compilers ship with this library.

Interesting.  Went off and familiarized myself with Dinkum EC++.  This
in part, because I recalled having a conversation with the vendor and
he seemed overly enthused about the fact that the lastest release of
their development environment used 'Dinkumware'.  To that end, he
offered me a trade +  extra cash.
Trouble is, I tend to be a little skeptical of a sale person who
doesn't do a good job of explaining to me the ' embedded ' in the
embedded version of the Dinkumware C++ compiler.


Curiousity question.  What's in a name - 'Dinkumware'?


Re: C++ STL in embedded systems

Quoted text here. Click to load it

Short answer -- we spent a year in Australia. A good friend of mine
organized a visiting post for me at University of New South Wales.
Besides, we've always liked Oz. "Dinkum" is Aussie slang for
genuine, honest, or true. I thought it was a good name for a
company that made good software. (The Limited part is to keep us
humble.)

Longer answer -- One term I taught a graduate seminar in software
engineering. (I called it Remedial Software Engineering.) We had
a running case study on Dinkum Swill Pty. Ltd., a company that
supplied hog swill for most of NSW. The students found some
fascinating, and sometimes gross, uses for computers in the
production of hog swill.

A few years later, I found myself negotiating with the likes of
Microsoft and IBM for the licensing of the C++ library I'd been
developing. My wife Tana did not want me signing contracts with
such big players as a sole proprietor (quite rightly). So she
founded a company for us. I wanted to call it Dinkum Swill, but
she would have none of it. (Imagine sitting at a rosewood
conference table explaining to a bunch of suits where the name
came from.) She was willing to settle for Dinkumware, Ltd.

That was ten years ago.

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Site Timeline