Boost logo

Boost :

From: Thomas Wenisch (twenisch_at_[hidden])
Date: 2002-09-01 15:24:59


On Sun, 1 Sep 2002, Carlo Wood wrote:

> On Fri, Aug 30, 2002 at 01:53:44PM -0400, Thomas Wenisch wrote:

[snip]
> >
> > By the same token, I think that it is a LOT of work to get a demangler
> > that only uses pre-allocated memory, and it may not even be possible, so
> > I'm not sure that this should be a design goal of a general-purpose name
> > demangling library. Such a demangler would probably have to be tightly
> > integrated with the rest of your debugging framework (ie stack trace
> > capture without allocating memory, exceptions that use pre-allocated
> > memory, etc). Since this is not the most common use case, IMHO, I believe
> > the extremely low memory situation should not be a primary concern now.
>
> It is not - the code is already written anyway. And by providing
> the Allocator template argument it will be easy for users to pass on
> an Allocator that uses pre-allocated memory as well. So I think your
> example is only another reason to indeed provide an interface that
> accepts to pass an Allocator type instead of always using the
> std::allocator.

Well, if it not difficult, and already done, then by all means, I
wholeheartedly support being able to swap out the allocator. I also don't
think the extra compilation time due to having to instantiate the
demangler as opposed to simply linking with it is a big deal -
Considering libraries like template meta-programming library (MPL) and the
Lambda library, Boost users seem to be ready to pay extra compilation time
for new features.

I do think Doug (I believe it was Doug) is right that the interface should
completely hide the Allocator issue from those users who don't care. Even
having to specify std:allocator as an explicit template argument increases
complexity for users who never change their allocator (and thus, may not
even know enough about STL to do so).

Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk