This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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