This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::string exorcism hiccup
> OK, I don't claim to be clever enough to post a solution this issue in
> the context of a 5-minute e-mail, but I'd agree that this internal
> implementation policy should be more tunable for embedded platforms.
> The problem is that most traditional solutions to this problem would
> require a complete recompilation of the library... (In fact, I must
> concede that the __USE_MALLOC recompilation option might be the best
> case for tiny embedded systems; since by starving themselves of
> memory, they have all but agreed to the Faustian pact with the Devil)
The general solution lies somewhere in the elimination of a precompiled
libstdc++.a, If libstdc++ was entirely based on automatically instantiated
templates, then a simple global #define would suffice.
I guess compiler technology just isn't upto this job yet, but what I wonder
how far off it is?
In the mean time, the solutions are either:
__USE_MALLOC
or
override the entire contents of functexcept.o - i.e. all the
internalstd::__throw_logic_error type calls, and get them to throw some
better behaved type of exception, and live with the fact that non-standard
exceptions will be thrown.
Both nasty in their own little way.
I'm doing the second since I get better memory allocation (malloc needs an
size_t tacked onto the front of each block, STL type allocators don't).