Re: Memory, Allocator<T> & __USE_MALLOC & alternatives

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20020609130445.1720A56F7@kidstv.dyndns.org> you write:

> I'm using libstdc++ in a small (96K ROM, ~20K usuable RAM) embedded sh-elf
> project. I've just tracked down what I thought was a memory leak,
> but is actually a feature.

Yes, it is true that libstdc++ is configured by default to perform
well on systems with memory...

I will attempt to answer as "the last guy" to worry about this stuff
(back before the gcc 3.0 release).

> OK, so the solution seems obvious - use __USE_MALLOC, which, despite being 
> not the greatest performing system in the world - it produces a workable 
> solution.

Yes, if you have a compacting malloc() implementation, this would be a
correct course of action (aside, perhaps we need to make it easier for
cross environments, known to have small memory models, to get this
configuration).  However, as you know, some systems contain a malloc()
implementation that retains chucks of size X in a cache without
recombining into larger chunks. (usually, when the system has gobs of
memory, I suppose... ;-)

> I'll do the work, if there's a chance of somebody applying it to the CVS. 

Regarding the work you propose to do, please feel free to post any
patches that you use that work better with embedded targets.  Likely,
we need to worry about your FSF paperwork status.

Also, I would like to ask you to consider another option as a
direction for your work.  It was common in my experience with C
embedded systems that the application wants to tightly control
allocation of memory.  Thus, I wonder if instead of a global policy to
change the default allocator, if you couldn't override the allocator
for STL objects and containers when declaring them.  This way the
matter is controlled in the application source code (make a point of
indirection through a single typedef to make late tuning easier)
instead of yet another #ifdef controlled option that causes
recompilation of the entire library...  Thus, I would see your work as
providing an optional allocator at the definition point of all STL
objects instead of as a global option.

BTW, I've been reading ``Modern C++ Design'' by Alexandrescu.  It
further inspires my thinking about killing every last #ifdef option
possible (esp. when they were used as a means of global system/library
tuning).

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672