Re: ext/mt_alloc.h

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

In article <20030521183008.2089e4bc.bkoz@redhat.com>,
Benjamin Kosnik<bkoz@redhat.com> writes:

>>> My and Ola's FSF assignments are now near completion (we have sent back 
>>> signed assignment papers last week).

> These assignments are now ready to go. This code can be integrated.
> (Gwain's assignment is still in progress.)

> I'm still in favor of moving extra things out of namespace std in
> stl_alloc.h and into ext. Does anybody have strong feelings about this?

No.  It does seem that anything not in the standard should be outside
namespace std and/or named using our implementor space (i.e. leading
underscores, etc).  Also, it does seem that almost everything we
advertise to users should not be named in our implementor space.

> Another issue is to try and extend GLIBCPP_FORCE_NEW into someting like
> GLIBCPP_SELECT_ALLOCATOR. Thoughts?

Well, as a first step, if I could mandate anything it would be that
all allocators that we ship in std and/or __gnu_cxx support
GLIBCPP_FORCE_NEW in order to disable all their complex behavior.
This feature supports debugging of an application as-built.

I think that there is little value in allowing users to override
allocator behavior globally from simple -> complex.  The reason is
that most of the required tuning must be done on a per-situation
basis.  It is possible that this new MT pool allocator will be better
in all cases on some platforms.  If so, then I'd rather see it become
the new default on said platforms.  However, I think we would need
more data before changing the default for all platforms.

Regards,
Loren