Re: [boost] Re: [Libcwd-devel] libcwd and Boost

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-08-30 09:01:12

From: Toon Knapen <toon.knapen_at_[hidden]>
> On Friday 30 August 2002 09:30, Rob Stewart wrote:
> > From: Carlo Wood <carlo_at_[hidden]>
> >
> > >    b) The interface needs to allow one to provide an allocator<> to
> > >       use internally for (temporary) allocations (strings and internally
> > >       used STL containers).
> >
> > Why isn't the default appropriate?  As long as your code
> > allocates and destroys its own memory, it's memory allocations
> > will not need to interact with those of your callers.
> 
> but you might want to get some memory-space from the application that you can 
> use to quickly create and destroy temporaries. An allocator would be a good 
> solution. The application can also provide an interval of addresses in memory 
> that can be used by this component for doing placement-new's.

I still don't see the point.  The library code can allocate and
deallocate memory as it sees fit.  It can use new/delete,
std::allocator<...>, or whatever.  As long as the library doesn't
allocate memory and hand it off to the caller, or if the memory
allocation is managed in an object that defers to the library to
release it, there is no problem.

Only if the library tries to return a std::string, for example,
do you run into a potential problem.  The library's allocator
will allocate the memory, possibly from a separate heap, but the
caller's code won't realize that the allocator in the string
isn't equivalent to the one it has access to.  The problem will
be one allocator allocating on one heap and another trying to
delete from another.

> > > At this moment the interface is as follows:
> > >
> > > void demangle_type(char const* input, std::string& output);
> > > void demangle_symbol(char const* input, std::string& output);
> >
> > void demangle_type(std::string & t_o, std::string const & t_i);
> > void demangle_symbol(std::string & s_o, std::string const & s_i);
> >
> why not 
> void demangle(std::string& o, const std::type_info& i)
> to avoid the C-style argument overloading.

I agree that eliminating the possibility for reversing the
arguments is valuable.  I presumed that the string interface was
to give a little more flexibility wrt where the type string came
from.  There are many cases where the version I proposed will
work fine because a temporary can't be bound to the output
parameter, but it isn't foolproof.

> I  would prefer though
> std::string demangle(const std::type_info& i)
> because e.g. it's easier to use it in 
> std::cout << demangle( typeid(a) ) << std::endl;

That is, indeed, easier to use, and it was my first thought.
However, if the library is a shared object or DLL, then you have
heap management problems as described above.

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