By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,934 Members | 1,677 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,934 IT Pros & Developers. It's quick & easy.

C++ STL in embedded systems

P: n/a
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

Jan 3 '06 #1
Share this Question
Share on Google+
49 Replies


P: n/a
"Alex Vinokur" <al****@users.sourceforge.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Are there any restrictions/problems for use of C++ STL in development
in embedded systems?
Perhaps. That depends upon the implementation and
the platform (and perhaps other criteria, such as
the nature of your application).
In particular:
* Does STL require too much space/memory?
How much is too much? Also note that each specific
standard library implementation may consume different
amounts of resources.
* Is 'implementation of STL algorithms/methods' reenterable/reentrant?
That depends upon the implementation.
* What is the cost to provide continuity of vectors in memory?
Not sure what you mean my 'continuity'. However, the elements
of a std::vector object are required to be contiguous in memory.
Any other problems?


Perhaps.

-Mike
Jan 3 '06 #2

P: n/a
Alex Vinokur wrote:
Are there any restrictions/problems for use of C++ STL in development
in embedded systems?
I think I am confused by the use of the second 'in' here. Do you mean
'for' or 'on'? If you develop elsewhere and then install your program
to run on an embedded system, that's "for". If you try to compile your
program so that the compiler is running right there, it would be "on"
an embedded system. Which one are you interested in?
In particular:
* Does STL require too much space/memory?
You need to define "too much". However, generally speaking, the library
design is such that the objects do not introduce enormous overhead.

Since most of the Standard library is templatised, the compiler does need
more memory for processing the code that does use templates than code that
does not. So, the difference usually exists during compile-time and not
in run-time.
* Is 'implementation of STL algorithms/methods' reenterable/reentrant?
Generally, probably yes. However, the Standard says that non-reentrancy
is implementation-defined (17.4.4.5). Look in the documentation for your
compiler.
* What is the cost to provide continuity of vectors in memory?
I don't understand the question. Vectors are contiguous. Each vector
object requires some memory for itself and then some overhead exists for
dynamic array allocation. That's essentially the cost.
Any other problems?


I have no answer here, but I am sure others who program for embedded
systems, do.

V
Jan 3 '06 #3

P: n/a

Victor Bazarov wrote:
Alex Vinokur wrote:
Are there any restrictions/problems for use of C++ STL in development
in embedded systems?
I think I am confused by the use of the second 'in' here. Do you mean
'for' or 'on'? If you develop elsewhere and then install your program
to run on an embedded system, that's "for".


It should be 'for'.
Thanks.
If you try to compile your
program so that the compiler is running right there, it would be "on"
an embedded system. Which one are you interested in?
In particular:
* Does STL require too much space/memory?
You need to define "too much".


I would like to know of experience of people working with STL for
embedded systems.
Are there hard/insoluble problems related to issue?
However, generally speaking, the library
design is such that the objects do not introduce enormous overhead.

Since most of the Standard library is templatised, the compiler does need
more memory for processing the code that does use templates than code that
does not. So, the difference usually exists during compile-time and not
in run-time.
* Is 'implementation of STL algorithms/methods' reenterable/reentrant?


Generally, probably yes. However, the Standard says that non-reentrancy
is implementation-defined (17.4.4.5). Look in the documentation for your
compiler.
* What is the cost to provide continuity of vectors in memory?


I don't understand the question. Vectors are contiguous. Each vector
object requires some memory for itself and then some overhead exists for
dynamic array allocation. That's essentially the cost.


Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for v.size()
== 30000.

P.S. By the way, does similar continuity problem exist for ordinary
array?
[snip]

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

Jan 3 '06 #4

P: n/a
Alex Vinokur wrote:
[...]
Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.
What's v.capacity() ?
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for v.size()
== 30000.
Unknown. Depends on the capacity.
P.S. By the way, does similar continuity problem exist for ordinary
array?


Ordinary array has a fixed size, and no 'push_back' member function, so,
no, such problem does not exist there.

V
Jan 3 '06 #5

P: n/a
Alex Vinokur wrote:
Victor Bazarov wrote:
Alex Vinokur wrote: [snip]
* Does STL require too much space/memory?
You need to define "too much".


I would like to know of experience of people working with STL for
embedded systems.
Are there hard/insoluble problems related to issue?


Presumably you mean, "Are there hard/insoluble problems related to
[this] issue [i.e., too much memory being required]?"

I have used STL on several different processors on embedded systems,
and I have had no problems related to memory usage that wouldn't have
also been incurred by statically allocated or new/malloc allocated
memory. However, problems related to std::vector certainly could be
incurred on an embedded (or other non-embedded!) system, especially
because of its exponential memory allocation strategy. Some embedded
systems have tighter memory requirements than others, so it will
entirely depend on your requirements. However, see below on how to
mitigate potential memory issues.

[snip]
* What is the cost to provide continuity of vectors in memory?


I don't understand the question. Vectors are contiguous. Each vector
object requires some memory for itself and then some overhead exists for
dynamic array allocation. That's essentially the cost.


Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for v.size()
== 30000.


std::vector allocates memory exponentially to "amortize" the growing
cost over time. Consequently, when you do your first push_back, vector
will double its size (i.e., allocate a second buffer of double the
size, copy the existing data into it, and then delete the first
buffer), and when you exceed the new size, it will double it again to
40000. So this will (1) waste memory if the vector doesn't grow any
more beyond that, (2) take up some extra memory while you're doing the
copy, and (3) possibly fragment memory beyond repair.

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.
P.S. By the way, does similar continuity problem exist for ordinary
array?


Yes, and it must be done by hand, which is more error prone. However,
you do then control the memory allocation strategy and could make it
something other than exponential if your system demands it (e.g., add
some predefined amount to the current size, allocate that mem, and then
copy the old into the new; or use some sort of "chunk allocator", where
non-contiguous chunks are tracked by a linked list; etc.).

Cheers! --M

Jan 3 '06 #6

P: n/a
mlimber wrote:
Alex Vinokur wrote:
Victor Bazarov wrote:
Alex Vinokur wrote:
[snip] Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for v.size()
== 30000.


std::vector allocates memory exponentially to "amortize" the growing
cost over time. Consequently, when you do your first push_back, vector
will double its size (i.e., allocate a second buffer of double the
size, copy the existing data into it, and then delete the first
buffer), and when you exceed the new size, it will double it again to
40000.

[snip]

Note: This discussion assumed that v.size() == v.capacity().

Cheers! --M

Jan 3 '06 #7

P: n/a
>> Are there any restrictions/problems for use of C++ STL in development
in embedded systems?
You might want to think about exception handling.
* Does STL require too much space/memory?
for a small system, yes. But if you need the functionality, it's probably
better than writing it yourself.
Any other problems?


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
Jan 3 '06 #8

P: n/a
Alex Colvin wrote:
Are there any restrictions/problems for use of C++ STL in development
in embedded systems?


You might want to think about exception handling.

[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

Jan 3 '06 #9

P: n/a
>> >> Are there any restrictions/problems for use of C++ STL in development
>> in embedded systems?
You might want to think about exception handling.

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


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
Jan 3 '06 #10

P: n/a
Alex Vinokur wrote:
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?


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-

Jan 4 '06 #11

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Vinokur wrote:
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?

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+AJ0c3bCEdHDsiKzEhM6AEk 3PIBYtvACeNRTa
jB2W3uidBsbZsnsViEz7eB0=
=bBVe
-----END PGP SIGNATURE-----
Jan 4 '06 #12

P: n/a

Victor Bazarov wrote:
Alex Vinokur wrote:
[...]
Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.
What's v.capacity() ?
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for v.size()
== 30000.


Unknown. Depends on the capacity.


Is the capacity is too big, will 'v' be reallocated/copied?
P.S. By the way, does similar continuity problem exist for ordinary
array?


Ordinary array has a fixed size, and no 'push_back' member function, so,
no, such problem does not exist there.

[snip]

I meant use of 'realloc'.

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

Jan 4 '06 #13

P: n/a
Alex Vinokur wrote:
Victor Bazarov wrote:
Alex Vinokur wrote:
[...]
Let v be of vector<in> type.
For instance, at the moment v.size() = 10000.


What's v.capacity() ?
Now we do the following thing:
for (int i; i < 20000; i++) v.push_back(i);

Must 'v' be reallocated/copied to provide its continuity for
v.size() == 30000.


Unknown. Depends on the capacity.


Is the capacity is too big, will 'v' be reallocated/copied?


I would rather use the words "large enough" instead of "too big", but
if what you meant was "if the capacity is larger than 30000", then no
reallocation would be necessary.
P.S. By the way, does similar continuity problem exist for ordinary
array?


Ordinary array has a fixed size, and no 'push_back' member function,
so, no, such problem does not exist there.

[snip]

I meant use of 'realloc'.


I don't understand this statement. Use of 'realloc' for what?
'realloc' allocates another object and copies the contents. It is
a _deliberate_ action. There is no automatic growing of arrays.

And, according to the Standard, 'realloc' returns a pointer to
a _new_ object (array), whereas the original one is deallocated.
There is no analogy with 'std::vector' whatsoever. But do look
at an implementation of one.

V
Jan 4 '06 #14

P: n/a
In comp.arch.embedded Alex Colvin <al***@theworld.com> wrote:
The result seems to be that C++ has become unstable.


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 (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Jan 4 '06 #15

P: n/a

Victor Bazarov wrote:

[snip]
'realloc' allocates another object and copies the contents. It is
a _deliberate_ action. There is no automatic growing of arrays.

And, according to the Standard, 'realloc' returns a pointer to
a _new_ object (array), whereas the original one is deallocated.
There is no analogy with 'std::vector' whatsoever.


How is 'continuity of vectors in memory' provided? Without using
reallocation/deallocation?

[snip]

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

Jan 4 '06 #16

P: n/a
Alex Vinokur wrote:
'realloc' allocates another object and copies the contents. It is
a _deliberate_ action. There is no automatic growing of arrays.


How is 'continuity of vectors in memory' provided? Without using
reallocation/deallocation?

"automatically" :)

Seriously though, the way vectors grow is just an implementation detail
- different implementations will do it differently - only the semantics
are consistent across implementations.

In your case, if you *do* care about the way it is implemented, then I
would suggest try to find (if possible) a standard library
implementation that's intended to be used in an embedded system. Or
you also might find more convenient to use a custom allocator if you
have memory constraints (be aware of type incompatibilities though,
with the existing C++ standard). If you have other constraints (apart
from memory constraints) then roll out your own "vector", implemented
with whatever contraints you have.
Hope this helps,
-shez-

Jan 4 '06 #17

P: n/a
Alex Colvin wrote:
>> Are there any restrictions/problems for use of C++ STL in development
>> in embedded systems?

You might want to think about exception handling.[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).


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.


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.
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.).
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).
As implementations like GCC approach conformance,
their libraries have to keep changing.
Can you give an example? The library implementations might be refined
or tweaked behind the scenes, but the interfaces should generally be
stable.
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.


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

Jan 4 '06 #18

P: n/a
Alex Vinokur wrote:
Victor Bazarov wrote:

[snip]
'realloc' allocates another object and copies the contents. It is
a _deliberate_ action. There is no automatic growing of arrays.

And, according to the Standard, 'realloc' returns a pointer to
a _new_ object (array), whereas the original one is deallocated.
There is no analogy with 'std::vector' whatsoever.


How is 'continuity of vectors in memory' provided? Without using
reallocation/deallocation?


std::vector does sometimes use the allocated-copy-destroy mechanism
while it is growing (see my other post for more details). std::realloc
does a similar thing with malloc'ed memory and POD types when the size
passed to std::realloc is larger than the current size. The difference
is that std::vector works on non-POD types as well.

You might be interested in these articles by Andrei Alexandrescu:

http://www.cuj.com/documents/s=7992/...r/alexandr.htm
http://www.cuj.com/documents/s=7990/...r/alexandr.htm
http://www.cuj.com/documents/s=7988/...r/alexandr.htm

They describe generic typed buffers, which are somewhere in between
built-in arrays (which are evil; see the FAQ) and std::vector, which
may not have acceptable performance for certain applications. The third
discusses realloc and growing in gory detail.

Cheers! --M

Jan 4 '06 #19

P: n/a
On 3 Jan 2006 10:47:05 -0800, "Alex Vinokur"
<al****@users.sourceforge.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.

Not all those who wander are lost. - J.R.R. Tolkien
Jan 4 '06 #20

P: n/a
"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.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
Jan 4 '06 #21

P: n/a
P.J. Plauger wrote:
"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.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

Jan 4 '06 #22

P: n/a
"JustBoo" <Ju*****@BooWho.com> wrote in message
news:85********************************@4ax.com...
On 3 Jan 2006 10:47:05 -0800, "Alex Vinokur"
<al****@users.sourceforge.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
Jan 4 '06 #23

P: n/a

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

Jan 4 '06 #24

P: n/a
"Alex Vinokur" <al****@users.sourceforge.net> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.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
Jan 4 '06 #25

P: n/a
|| 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.

Jan 4 '06 #26

P: n/a
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.

Jan 4 '06 #27

P: n/a

P.J. Plauger wrote:
"Alex Vinokur" <al****@users.sourceforge.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

Jan 5 '06 #28

P: n/a

P.J. Plauger wrote:
"Alex Vinokur" <al****@users.sourceforge.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

Jan 5 '06 #29

P: n/a
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_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

Jan 5 '06 #30

P: n/a

Alex Vinokur wrote:
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

Jan 5 '06 #31

P: n/a
"Alex Vinokur" <al****@users.sourceforge.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
P.J. Plauger wrote:
"Alex Vinokur" <al****@users.sourceforge.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?


Yes.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jan 5 '06 #32

P: n/a
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?

Jan 5 '06 #33

P: n/a

ma740988 wrote:
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

Jan 5 '06 #34

P: n/a
mlimber wrote:
void Increment1( int& i )
{
const volatile n = 10;


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

Jan 5 '06 #35

P: n/a
|| 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 :)

Jan 5 '06 #36

P: n/a
ma740988 wrote:
|| 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

Jan 5 '06 #37

P: n/a
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.

Jan 5 '06 #38

P: n/a
|| 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.

Jan 5 '06 #39

P: n/a
Alex Vinokur wrote:
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

Jan 5 '06 #40

P: n/a
ma740988 wrote:
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?


The relocations don't matter from a *logical* standpoint; i.e. from the
standpoint of *what* the program will do when executed. Sure, it
matters a great deal from a *practical* standpoint, i.e. in terms of
real-world performance, but that's not the same thing.

--
Mike Smith
Jan 5 '06 #41

P: n/a
ma740988 wrote:
|| 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?


No, but the *output of the program* would be the same. That's what was
meant by "logically redundant"; i.e. the difference is a *practical*
one, not a *logical* one.

--
Mike Smith
Jan 5 '06 #42

P: n/a
AD wrote:
I did face few issues when introducing STL in a vxWorks based
system.Major problems were:
- significant code bloat

....

It would be nice if there were alternative implementations of the
containers (especially map/set) where most of the code was non-
templated and used void * and function pointers heavily. The
templates would just be a type-safe veneer. Seems like this
approach would be a little less fast but could greatly reduce
bloat (in those bloat-sensitive situations).

Has anyone tried this?

Jan 6 '06 #43

P: n/a
Hans-Bernhard Broeker wrote:
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.


Interesting... How many C++ standards have you come around? Sounds
like quite a lot! However, there is exactly one C++ standard and
there will be a revision which is expected around the end of this
decade. Yes, the target moves - with more than ten years of stability
between moves.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Jan 6 '06 #44

P: n/a

|| 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'?

Jan 9 '06 #45

P: n/a
"ma740988" <ma******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
|| 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'?


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
Jan 10 '06 #46

P: n/a
Alex Vinokur wrote:
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?

If you are wondering about microsoft's evc++ 4.0 and above, the simple
answer is, they don't provide one due to yada yada reasons. Every
platform has its own library, and their MFC has a memory leak. You can
possibly get sources for the STL and compile them with each library for
each platform that you are working for. But it is not clear if evc++ is
truly standards conforming.
--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn


Jan 23 '06 #47

P: n/a
"Shark" <cp*******@yahoo.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Alex Vinokur wrote:
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?


If you are wondering about microsoft's evc++ 4.0 and above, the simple
answer is, they don't provide one due to yada yada reasons. Every
platform has its own library, and their MFC has a memory leak. You can
possibly get sources for the STL and compile them with each library for
each platform that you are working for. But it is not clear if evc++ is
truly standards conforming.


If by STL you really mean the Standard Template Library, then most
versions of eVC++ contain pretty complete implementations. (Ours, of
course.) What Microsoft has managed to do, for mysterious (yada
yada?) reasons, is butcher the combined C/C++ library in bizarre and
inventively different ways for each release of eVC++. We have a tidy
side business replacing the missing bits for those who need better
code portability between desktop and embedded versions of the same
compiler family.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jan 23 '06 #48

P: n/a
"P.J. Plauger" wrote:
"Shark" <cp*******@yahoo.com> wrote in message
Alex Vinokur wrote:

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?


If you are wondering about microsoft's evc++ 4.0 and above, the
simple answer is, they don't provide one due to yada yada reasons.
Every platform has its own library, and their MFC has a memory
leak. You can possibly get sources for the STL and compile them
with each library for each platform that you are working for. But
it is not clear if evc++ is truly standards conforming.


If by STL you really mean the Standard Template Library, then most
versions of eVC++ contain pretty complete implementations. (Ours,
of course.) What Microsoft has managed to do, for mysterious (yada
yada?) reasons, is butcher the combined C/C++ library in bizarre
and inventively different ways for each release of eVC++. We have
a tidy side business replacing the missing bits for those who need
better code portability between desktop and embedded versions of
the same compiler family.


The reason is obvious and consistent. Microsoft fouls existing
standards in order to lock suckers in to their own software and
systems. They have been doing this for many years. They have
fouled html with IE and Usenet with OE. More power to you if you
can replace their junk with conforming packages.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Jan 23 '06 #49

P: n/a
Shark wrote:
Alex Vinokur wrote:
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?
If you are wondering about microsoft's evc++ 4.0 and above, the simple
answer is, they don't provide one due to yada yada reasons. Every
platform has its own library, and their MFC has a memory leak. You can
possibly get sources for the STL and compile them with each library for
each platform that you are working for.


First, eVC++ 4.0 includes STL implementation but very incomplete.
Second, if you'd like to use STL then you have two (three in fact) choices:
- buy Dinkumware libraries
- use STLport (here is my small introduction: http://tinyurl.com/eysea)
- write it youself :-)

But it is not clear if evc++ is
truly standards conforming.


No, it isn't e.g. there is lack of template partial specialization
support and other modern C++ features.
eVC++ compiler is directly derived from VC++ 6.0 for desktop Windows.
(BTW, compilers for Windows CE platform are usually based on "big"
brothers for desktop Windows)

If you are looking for ANSI/ISO C++ compliant compiler for Windows CE
then you better take a look at Visual C++ 2005 (8.0).
Here is my small analysis I write to encourage myself to
move to VC++ 8.0 :-)

http://mateusz.loskot.net/2005/12/28...ng-windows-ce/

Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
Jan 23 '06 #50

This discussion thread is closed

Replies have been disabled for this discussion.