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

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-08-30 08:30:36

From: Carlo Wood <carlo_at_[hidden]>
> 
> If this is to succeed, then please realize that when I mail you - all
> work will stop on it when I don't get a mail back;  this has happened
> before many times, so I'll be so unpleasant bringing it up immedeately:
> The release of this library as a boost library is a "project", when I
> mail you (or the list), the project stalls when I don't get an answer
> (and there will be no release at all in that case).  This is not meant
> as a threat - I just never understood why people stop responding to
> communication - so whatever reasons anyone might have, I just want them
> to be clearly aware of the result.

People have lives outside of Boost, so you may not get immediate
responses, but the list is very active.  I don't think you'll have
a problem unless communicating with you becomes frustrating for
the interested parties.

>    a) I'd like to release it as a C++ library - not for C applications thus.

Since Boost is a C++ group, that won't be troublesome.

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

>    c) If (a part of) the interface uses std::string for its output
>       (the input should be char const* no?), then there must be a

I don't see how that follows.  The input might reasonably be char
const *, but I don't see the connection.

>       matching interface that uses a basic_string using the fore mentioned
>       allocator.

If you don't allocate the string for the caller, then you don't
need an allocator from the caller.

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

Based upon my allocator comments above, I think not returning a
string is appropriate.  Given your interface, an allocator isn't
needed unless I've missed something.

I don't see anything wrong with the following:

void demangle_type(std::string & t_o, std::string const & t_i);
void demangle_symbol(std::string & s_o, std::string const & s_i);

(Names shortened to avoid wrapping; suffixes added to clarify
input versus output.)

> The first can be used to demangle strings as returned by typeid(OBJECT).name(),

A parameterized version that does the typeid(T).name() for the
caller would be useful:

template <typename T>
inline
void
demangle_type(std::string& t_o, T const & t_i)
{
   demangle_type(t_o, typeid(t_i).name());
}

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