On 21.09.2011 22:05, Paul D. DeRocco wrote:
> The problem with what was once called STL (which has actually been part of
> the C++ language since 1998) is that it has no way to report out-of-memory
> errors other than by throwing bad_alloc. uSTL doesn't seem to be any
> different. But last I looked, eCos didn't support C++ exceptions, because
> the kernel didn't provide the helper functions needed to make them
> thread-safe. eCosCentric's version did, but that was something you could
> only use if you bought their package. Is this still the case? I haven't
> worked with eCos for about four years now, so I haven't been keeping track.
For the record: the libstdc++ from recent enough gcc (at least
since 4.4, probably since 4.2) compiles and runs perfectly well
on eCos/ARM.
I can't comment on the thread-safety issues as we are intentionally
not using the exceptions in our code. If there is an out of memory
condition in an embedded system in most of the cases the system is
stuffed anyway and the thread-safety of exceptions is the least
problem. Just reboot the box and hope it goes away - trying
to recover is a problematic task.
One issue is that the libstdc++ pulls in a non-trivial amount
of useless code regarding pretty-printing stack on abort
or something. This can be worked around using some
command-line option magic but if the uSTL suffices your
needs, maybe it is a better route on memory-constrained
devices.
Regards
--
Stano
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
