Boost logo

Boost :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-08-30 14:54:03

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.

> > 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);
> I find that putting output parameters first is a better
> arrangement. First, because they are somewhat unusual, they will
> stand out a bit better. Second, putting them first allows for
> default parameters when desired.

I agree completely. Pitty though that STL always takes input parameters first
(e.g. std::copy)

> 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 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;

Boost list run by bdawes at, gregod at, cpdaniel at, john at