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
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
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
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.
-- Carlo "no nonsense" Wood
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk