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

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-30 08:57:03

At 06:51 AM 8/30/2002, Carlo Wood wrote:
At 06:51 AM 8/30/2002, you wrote:
>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).

The requirements are at http://www.boost.org/more/lib_guide.htm#License,
but that isn't literal text.  If you want to use the text that I did then
put this in every source file:

//  (C) Copyright Carlo Wood 2002. Permission to copy, use, modify, sell and
//  distribute this software is granted provided this copyright notice appears
//  in all copies. This software is provided "as is" without express or implied
//  warranty, and with no claim as to its suitability for any purpose.

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

You could wrap your uses of the allocator and string interface with
function objects or other such callbacks.  But I don't see why you
need to use the same allocator for temporary storage as for the
output string.