C++ STL in embedded systems

[Alex Vinokur]

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
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[P.J. Plauger]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

As to conformance, I don't know that I've run across a fully conformant
compiler/runtime yet.

No fully conformant compiler cum library exists, though some are close
and are available on a wide variety of platforms (GNU, Comeau, etc.).

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

[mlimber]

P.J. Plauger wrote:

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

As to conformance, I don't know that I've run across a fully conformant
compiler/runtime yet.

No fully conformant compiler cum library exists, though some are close
and are available on a wide variety of platforms (GNU, Comeau, etc.).

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.

I stand corrected.

Cheers! --M

[P.J. Plauger]

"JustBoo" <Ju*****@BooWho .com> wrote in message
news:85******** *************** *********@4ax.c om...

On 3 Jan 2006 10:47:05 -0800, "Alex Vinokur"
<al****@users.s ourceforge.net> wrote:

Are there any restrictions/problems for use of C++ STL in development
in embedded systems?

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.

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

[Alex Vinokur]

P.J. Plauger wrote:
[snip]

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.

[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

[P.J. Plauger]

"Alex Vinokur" <al****@users.s ourceforge.net> wrote in message
news:11******** *************@g 14g2000cwa.goog legroups.com...

P.J. Plauger wrote:
[snip]

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.

[snip]

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

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

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

[ma740988]

|| If you know how big it will grow (or even approximately how big),
you
|| can use std::vector<>:: reserve() to set the initial capacity, which

|| will help minimize copying. If you do not know how big the size
will
|| grow and std::vector's memory allocation scheme doesn't work well
for
|| your system, you should probably not use them.

When dealing with embedded systems there seems to be a lot of fuss (
the word - which I'm opting to change - on the street in my world is:
Avoid it, unless absolutely necessary) about the use of the C++
Standard Library ( most still refer to it as STL ). Language
linguistics aside, the worse case scenario here amounts to not knowing
how big a size required. But even so. With a C style array, the C
solution mirrors that of _allocating_ a large chunk of vector memory.
More memory than I might need. Am I missing something?

IOW: (i dont know how much memory I'll need). Well:

int *ptr_mem = new int[some_large_valu e]; // leave it for good -
hope to - whatever you believe in - it's enough.
or
int arr[some_large_valu e];

vector<int> myVec( some_large_valu e, 0 ); // leave it. may or may
not need some large value but hope to god it's enough.

[wkaras]

Alex Vinokur wrote:

Are there any restrictions/problems for use of C++ STL in development
in embedded systems?

....

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

http://www.geocities.com/wkaras/gen_cpp/avl_tree.html

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:

http://www.geocities.com/wkaras/heapmm/heapmm.html

All of the above code is designed to be reentrant.

[Alex Vinokur]

P.J. Plauger wrote:

"Alex Vinokur" <al****@users.s ourceforge.net> wrote in message

[snip]

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

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

[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

[Alex Vinokur]

P.J. Plauger wrote:

"Alex Vinokur" <al****@users.s ourceforge.net> wrote in message

[snip]

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

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

[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

[mlimber]

ma740988 wrote:

|| If you know how big it will grow (or even approximately how big),
you
|| can use std::vector<>:: reserve() to set the initial capacity, which

|| will help minimize copying. If you do not know how big the size
will
|| grow and std::vector's memory allocation scheme doesn't work well
for
|| your system, you should probably not use them.

When dealing with embedded systems there seems to be a lot of fuss (
the word - which I'm opting to change - on the street in my world is:
Avoid it, unless absolutely necessary) about the use of the C++
Standard Library ( most still refer to it as STL ). Language
linguistics aside, the worse case scenario here amounts to not knowing
how big a size required. But even so. With a C style array, the C
solution mirrors that of _allocating_ a large chunk of vector memory.
More memory than I might need. Am I missing something?

IOW: (i dont know how much memory I'll need). Well:

int *ptr_mem = new int[some_large_valu e]; // leave it for good -
hope to - whatever you believe in - it's enough.
or
int arr[some_large_valu e];
Right. Many of the same problems with growing a std::vector apply
equally to all other array-ish constructs. The main issue for embedded
systems, as I see it, is that std::vector grows exponentially, which
may be unacceptable or undesirable in some circumstances.
vector<int> myVec( some_large_valu e, 0 ); // leave it. may or may
not need some large value but hope to god it's enough.

You probably want to use reserve instead of allocating that many
elements straight away.

Cheers! --M