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

From: Carlo Wood (carlo_at_[hidden])
Date: 2002-08-30 07:51:48

On Wed, Aug 21, 2002 at 12:49:54PM -0400, David Abrahams wrote:
> At Boost, the rule is "he who contributed the sweat retains control over
> the source", so I don't think that's very far from your philosophy.
> Normally you would retain the library's copyright.
> 
> > It would be unacceptable to me when others would re-implement the
> > functionallity of libcwd into another library - making me lose
> > my user base because they can get the same elsewhere in for example
> > a widely used 'standarization' work as Boost.
> 
> The solution would be for you to become a Boost developer, and contribute
> some portion of libcwd as a boost library.

Ok... lets start with the demangler then.

Many people (gdb, gcc, libiberty, companies, you, other developers)
have begged me to release this code - there seems to be a great
need for it.

I need some help with this though :).

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.

Here is what I need a response to:
1) Please provide me with the *literal* text that I need to put
   in each source file, and with the main text that is needed
   in the 'root' of the project in order to have a boost compatible
   library.  If you must give an url, it better point to literal
   texts - I am not very creative when it comes to licenses :/
   (I hate them).

2) I have a few issues that are important to me; this might need
   discussion.
   a) I'd like to release it as a C++ library - not for C applications thus.
   b) The interface needs to allow one to provide an allocator<> to
      use internally for (temporary) allocations (strings and internally
      used STL containers).
   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
      matching interface that uses a basic_string using the fore mentioned
      allocator.

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

The first can be used to demangle strings as returned by typeid(OBJECT).name(),
the second is for demangling symbols as are shown by 'nm' for example, and
__FUNCTION__, and whatever can be read directly from the symbol table of
an object file.

3) I'd like to have a brainstorm session from other developers about a
   possible interface.

The main problem I am seeing is that when the allocator<> must be part
of the interface, then the whole library becomes a template library :/
At the moment I am using a fixed allocator and do not have this problem.

Regards,

-- 
Carlo "no nonsense" Wood