C++ STL in embedded systems

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

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

That depends upon the implementation.

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

Perhaps.

-Mike

You might want to think about exception handling.

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

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

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

I'm with the Embedded C++ folks 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.

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-

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.

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.

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

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

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

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.

Good Luck.

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

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.

I stand corrected.

Cheers! --M

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.

P.J. Plauger wrote: [snip]

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

Alex Vinokur email: alex DOT vinokur AT gmail DOT com

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

P.J. Plauger Dinkumware, Ltd.

...

If you need an ordered associative container that doesn't require elements to be copied into a general-purpose heap, consider:

At the other end of the spectrum, if your embedded system runs Linux (or some other OS with per-process memory protection and explicit shared memory), and you need to create an STL Allocator for shared memory, this code (in straight C) may be a useful starting point:

All of the above code is designed to be reentrant.

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

Thanks.

Alex Vinokur email: alex DOT vinokur AT gmail DOT com

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

Thanks.

Alex Vinokur email: alex DOT vinokur AT gmail DOT com

...

Here is a link to the slides for a 1999 presentation by Bjarne Stroustrup about using Standard C++ including the STL in embedded systems.

Yes.

P.J. Plauger Dinkumware, Ltd.