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

"Alex Vinokur" <a...@users.sourceforge.net> wrote in message 
news:1...@g14g2000cwa.googlegroups.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

>> 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 naïf

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

>> >> 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 naïf

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-

-----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+AJ0c3bCEdHDsiKzEhM6AEk3PIBYtvACeNRTa
jB2W3uidBsbZsnsViEz7eB0=
=bBVe
-----END PGP SIGNATURE-----

In comp.arch.embedded Alex Colvin <a...@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 (b...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

On 3 Jan 2006 10:47:05 -0800, "Alex Vinokur"
<a...@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