This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Standard Template Library



Hi,

>     Mahendra> 	Has anybody attempted to use Standard 
> Template Library
>     Mahendra> with ECOS ? If so, please give us information on your
>     Mahendra> attempts.
> 
> Not that I am aware of, but I can tell you about some of the issues
> that would have to be addressed.

We use STL in our new platform which is based on eCos. Some comments
about how we do stuff follows below. 

Currently we use the STLport (http://www.stlport.org/) implementation.

> 1) STL assumes C++ exception handling is available. Right now eCos is
>    built with -fno-exceptions, to keep down code size. I am not sure
>    offhand just what would be involved in getting C++ exceptions
>    going.

True, but some (most?) STL implementation can be configured not to use
exceptions. We do not use exceptions at all.

>    The same may be true of RTTI support, I do not know offhand whether
>    or not STL depends on RTTI. However RTTI support is a lot simpler
>    than exceptions, so this should not be a major hurdle.

I do not think STL requires RTTI. At least we get away without RTTI...
 
> 2) STL pretty much assumes dynamic memory allocation. You would have
>    to figure out how to map STL allocators on to the eCos dynamic
>    memory allocation support. This may just work if everything ends up
>    being mapped on to malloc() eventually, or more effort may be
>    needed/desirable.

We just use an allocator which maps directly to new (which in turn maps
to malloc()). Though we use our own dynamic memory allocator instead of
the eCos stuff (actually, we currently have a couple of different allocators 
tailored for different product lines).
 
> 3) thread-safety. The normal STL implementation can run on a number of
>    different thread implementations, including pthreads. You would
>    probably have to add support for eCos threading somewhere.

I think most STL implementations are thread safe only in the sense that
simultaneous access to distinct containers is safe and simultaneous read
access to the same container is safe. In other cases the client must do the
locking. Thus, typically the only part in STL that requires locking is the
allocators. Since we do not use the standard STL allocators we do not need
any eCos specific code at all in STL.

> For other parts of the C++ library, e.g. the I/O support, things get a
> bit more interesting. Much/all of this can be layered on top of a C
> library, but it needs to hook into the C library's stdio support in
> various ways. Again I do not know all the details.

We use a simple home grown (not quite standard) iostream implementation.
We do not have stdio and we do not use the eCos device driver stuff.

---
Lars Viklund
Axis Communications AB
SE-223 70 Lund, Sweden

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]