C++ STL in embedded systems

[P.J. Plauger]

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]

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]

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]

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_value]; // leave it for good -
hope to - whatever you believe in - it's enough.
or
int arr[some_large_value];

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

 

[wkaras]

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]

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]

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]

|| 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_value]; // leave it for good -
hope to - whatever you believe in - it's enough.
or
int arr[some_large_value];

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_value, 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

 

[wkaras]

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

....

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

http://public.research.att.com/~bs/esc99.html

 

[P.J. Plauger]

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

[snip]

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

Yes.

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

 

[ma740988]

With regard to the number below:

Read, sort, and write floating-point numbers

unoptimized optimized

elements C++ C C/C++ ratio C++ C C/C++ ratio

500,000 3.5 6.1 1.74 2.5 5.1 2.04
5,000,000 38.4 172.6 4.49 27.4 126.6 4.62


One of things I find interesting about the source - he used is his
comment:

buf.reserve(res); // logically redundant; for efficiency only

How is that 'logically redundant'. If you _dont_ call reserve. You'll
end up with a host of re-locations and the C++ numbers will be alot
worse. Am I missing something?

 

[mlimber]

With regard to the number below:

Read, sort, and write floating-point numbers

unoptimized optimized

elements C++ C C/C++ ratio C++ C C/C++ ratio

500,000 3.5 6.1 1.74 2.5 5.1 2.04
5,000,000 38.4 172.6 4.49 27.4 126.6 4.62


One of things I find interesting about the source - he used is his
comment:

buf.reserve(res); // logically redundant; for efficiency only

How is that 'logically redundant'. If you _dont_ call reserve. You'll
end up with a host of re-locations and the C++ numbers will be alot
worse. Am I missing something?

std::vector::reserve() only functions to speed things up; it doesn't
have an effect on the result of the program. Likewise, I might do this:

void Increment1( int& i )
{
const volatile n = 10;
i += n;
i -= (n-1);
}

void Increment2( int& i )
{
++i;
}

These two are logically equivalent (i.e., they do the same thing), but
the second is almost certainly more efficient.

Cheers! --M

 

[mlimber]

void Increment1( int& i )
{
const volatile n = 10;

Oops. That should have an "int" thrown in there.

 

[ma740988]

|| std::vector::reserve() only functions to speed things up; it doesn't

|| have an effect on the result of the program.
There to speed things up but doesn't affect the result of the program!!
Not just bear with me. You're saying that if I opt not use reserve
the end result (i.e the benchmarks) would be the same?

're-location' is a constant 'concern/gripe' when viewed from - what
seemingly is the most popular container. i.e the Vector. INMHO, it's
a much ado about nothing if you have a member function like reserve.
That said, if you opt _not_ to reserve, you're faced with the
copy/destroy/re-create saga. With your example 'benchmarks' will be -
for the most part - comparable. I'm not seeing how the benchmarks will
be comparable if he chose to call reserve ahead of time.

Time to pull out the compiler

 

[mlimber]

|| std::vector::reserve() only functions to speed things up; it doesn't
|| have an effect on the result of the program.

There to speed things up but doesn't affect the result of the program!!
Not just bear with me. You're saying that if I opt not use reserve
the end result (i.e the benchmarks) would be the same?

[snip]

No, I'm saying the sorted output of the program would be identical.

From a logical point of view, speed doesn't matter. Likewise,

Increment1() and Increment2() are identical in function (i.e. logically
the same) but different in implementation, which translates to speed of
execution for our current context.

Cheers! --M

 

[AD]

I did face few issues when introducing STL in a vxWorks based
system.Major problems were:
- significant code bloat
- incomplete STL support by the specific vxWorks version that we were
using. There were scores of linking errors whenSTL was used.Had to make
modifications to the STL header files to make it work.
- no concept of namespace on vxWorks (Everything happened to be in
default namespace)

But probably these issues are specific to vxWorks (and that too to a
particular version of it) and may not hold true for embedded system in
general. But Code bloat was definitely a problem and I found many
resources on Net which confirmed this problem of using STL in embedded
systems.

 

[ma740988]

|| But probably these issues are specific to vxWorks
|| (and that too to a particular version of it) and may not hold
|| true for embedded system in general

How long ago was this? I'm using vxWorks (Tornado IDE 2.2.1) - STL
and all. Doing FFT/IFFTs and Boundary Element Math withough a hitch.

|| But Code bloat was definitely a problem and I found many
|| resources on Net which confirmed this problem of using STL in
embedded
|| systems.
Is this relegated to 'embedded systems'? Furthermore, how do you
measure this 'code bloat'? I'm curious.

With all due respect. I think today (my experience) - this notion of
issues pertaining to STL usage in embedded systems is much ado about
nothing (lots of smoke and mirrors). My _real_ problem, is being stuck
with gcc 2.96. Beyond that. I've had no issues. Of course I haven't
measured code bloat yet but we'll see.

 

[Puppet_Sock]

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

[snip]

In general, you can't give a simple answer to such questions.
The specifics of how your particular embedded system works
are going to, in the extreme cases for various features, be the
choke point.

Consider a case where, for hardware reasons, you needed to
limit the amount of RAM on your system to the absolute
smallest possible amount. Anything that produced an extra
temp variable, an extra chunk of something shoved on the
stack, etc. etc., would be hard to accomodate. In such a case,
it might be easier to get your job done in some other language
than C++. Possibly assembler, for example. Though as time
goes by, the amount of RAM available on most hardware is
increasing. I recall a project from many years ago where
an industrial monitor (radiation hand and foot checker) had
a very small amount of RAM, like 128 bytes or some silly
small number. Trying to fit a C++ prog into such hardware
would have been tiresome. RAM is much cheaper these days.
The latest version of this device has a huge whack of RAM.

Other considerations: Suppose the system cannot require
human intervention, or human intervention is expensive in
some way. In such a case, a "bullet proof" implementation
that won't crash, won't leak resources, etc., is going to be
a big concern. A good implementation of the STL will look
pretty good in such cases, as compared to a roll-your-own
set of containers. So will reading the series of books
"Effective C++", "More Effective C++", and "Effective STL"
(though I may have munged the titles).

There are many other possible concerns. For example:
You need a compiler that outputs optimized code for
your hardware. This is crucial above all else. If the code
won't run on your hardware, there's no point worrying
about what library to use. So, if your compiler has limits
(not unusual in the case of hardware specific compilers,
though getting better) you should start with your list of
possible compilers, and figure out what is possible from
that. If the only compiler available is an older non-compliant
one, you may have trouble getting a good STL implementation
to work on it. I recall another project from many years ago
where the only compiler that would output code for the
hardware was a C compiler. And an old (1988 or so) C compiler
at that. Tiresome.

What other libraries are required for the project? If it's
a specific chunk of hardware, chances are there is an
API kit provided by the manufacturer. The advantages of
using such a kit may outweigh the advantages of using
the STL, supposing you can't use both. Though, again,
as time goes by most hardware makers are supporting
the STL, and more modern implementations of it.

There are many other possible considerations. For
example, if you explore these issues, the client might
be convinced that the extra RAM might be worth it in
order to be able to shorten the development time. Or
to be able to do the development in C++ rather than
assembler, and so be able to provide lots of new
sexy features in the same development time.
Socks