Re: [boost] Demangler, summary.

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-09-05 09:19:54

From: Carlo Wood <carlo_at_[hidden]>
> On Tue, Sep 03, 2002 at 12:28:45PM -0400, Rob Stewart wrote:
> > The problem here, then, is that demangle() might cause a recursive call to
> > malloc() in a naive implementation.  Therefore, you propose providing an
> > allocator for demangle() to use with its internal STL code, right?  It is also
> 
> Yes, although naive is not the word; either you try to demangle things
> from within malloc or you don't, and I do.

The point is, a naive implementation using STL classes would use
std::allocator<T> and that would be a problem.

> > my understanding that your use of STL containers, for example, is to collect and
> > cache symbol translations in order to improve performance.
> 
> No.

Well, could you please clarify why you need the STL containers, then?  I'm
getting quite confused about what you're doing and why.  I'm trying to
understand your need for the allocator to see if there are reasonable
alternatives or if there is no way to escape it.  If you're just going to
declare that you need it, don't want to hear about possible alternatives to that
need, and don't want to discuss this further, then say so.  In the meantime, my
hope is that I can better understand your needs and help you find a different
solution.

> [...]
> > Let's start with the assumption that an allocator is needed.  I'm left to wonder
> 
> It is :/

I thought this was a discussion to confirm or deny the validity of your claim.
I have been trying to understand what you're doing and why you need an
allocator.

> > what such an allocator can do.  Someone else just raised the question of what
> > the memory allocation scheme of that allocator should be?  Is it just a general
> > purpose function not unlike malloc()?  If so, then the demangle() client will
> > need to supply OS-specific private heap code in the form of std::allocator to
> > give you what you need.  That's a pretty tall order for most folks -- perhaps
> > for you, too.
> 
> It seems you don't know what an allocator is.  It is a template parameter
> that is passed to the STL containers.

I do know what an allocator is.  It is far more than a template parameter.  It
is a class that provides memory management.  I was discussing how an appropriate
allocator would be implemented to fulfill your requirement for an allocator
should that requirement be justified.  If my discussion wasn't making sense to
you, then perhaps you don't understand allocators as well as you think.

> The rest of your mail is off-topic as it is based on your misunderstanding
> of the subject.

It was on topic.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;