John Maddock wrote:

...

...

boost/graph/simple_point.hpp

I'm not responsible for this file.

...

...

boost/wave/util/flex_string.hpp

I'm not sure, what to do with this file. It was put by Andrei into the public domain. That's the reason why I didn't have inserted any Boost License into it.

Hmm, I guess as long as they're both clearly labelled as public domain then that's OK, one file has "The code is considered to be in the public domain", if you can add that to other file as well, then I'll update the licence scanner to recognise that. Actually "This code is considered to be in the public domain" would be somewhat better English, but that's being pedantic ;-)

Since I'm not a native English speaker I'd like to ask you for assistance here ;-) Please feel free to change the wording directly in the flex_string.hpp file. Regards Hartmut

Andrei Alexandrescu wrote:

...

...

Hmm, I guess as long as they're both clearly labelled as public domain then that's OK, one file has "The code is considered to be in the public domain", if you can add that to other file as well, then I'll update the licence scanner to recognise that. Actually "This code is considered to be in the public domain" would be somewhat better English, but that's being pedantic ;-)

Since I'm not a native English speaker I'd like to ask you for assistance here ;-) Please feel free to change the wording directly in the flex_string.hpp file.

Thanks very much for emailing me about flex_string. If you could also insert the following copyright notice, I'd be most grateful (beware of wrapped lines):

[snip] Done.

By the way, if anyone is interested in adding flex_string to boost :o), I have recently updated the code and reached a design and implementation I'm very happy with.

Since Wave is accepted into Boost, it is already :-P Could you please send this newest version to me, I'll try to update at least the flex_string contained in the Wave distro. Regards Hartmut

David Abrahams wrote:

...

...

By the way, if anyone is interested in adding flex_string to boost :o), I have recently updated the code and reached a design and implementation I'm very happy with.

Since Wave is accepted into Boost, it is already :-P

But it's not really in boost as an independent library, is it. Is it even exposed in the interface specification to Wave?

No and no. Was just kidding. It's certainly an implementation detail and completely exchangeable for any other std::string compatible class (simply by defining BOOST_WAVE_STRING=std::string or similar). Regards Hartmut

By the way, if anyone is interested in adding flex_string to boost :o), I have recently updated the code and reached a design and implementation I'm very happy with.

Will you be interested in submitting it? There is going to be a fixed string review soon. Common base for/cooperation in between fixed and dynamic string would be really interesting discussion. Gennadiy

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:

By the way, if anyone is interested in adding flex_string to boost :o), I have recently updated the code and reached a design and implementation I'm very happy with.

I suggest you start a new thread with an appropriate subject line, describing the basic capabilities of flex_string and querying interest. I suspect there will be lots :) Then if interest is high you could request a formal review. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Reece Dunn wrote:

Andrei Alexandrescu wrote: This is something that would be very useful, and something that would complement the fixed_string and const_string library proposals. However, there are a few limitations with the old version of flex_string (I am not sure about the new version - I am referring to the one used by wave).

Cool, I'll intersperse some comments.

[1] The interface does not allow for "natural-style" string declerations (like you can do with iterator_facade). That is, you have:

flex_string< char, const_string_impl< char > > my_str;

or something similar, instead of the more ideal

const_string< char > my_str;

This is something I have tried to address with detail::basic_string_impl in my fixed_string library.

Yah, that's been a problem with PBDs forever. Fortunately, unlike with smart pointers, the first template argument is less varied (mostly char, wchar_t, and int) so user- or library-level typedefs are more of an acceptable solution.

[2] The class is *huge* :). I know that this is a side-effect of the complexity of the std::string interface, and my version (based on flex_string) suffers from this as well.

My friend Florin Trofin has refactored the code in an attempt to address that. The file flex_string_shell.h contains the entire interface and hovers around 1000 lines. I think there's little that can be done about that if the basic_string interface is to be fully implemented. But fortunately, the policies themselves are, I think, of very manageable size even when they do nontrivial things. The simplest, VectorStringStorage, which I think is a very respectable policy, has only 111 lines.

One thing that I am looking into - but there are a lot of issues with - is trying to split up the design into usable, flexible components. That is, you could do:

class my_container: public sequence::reverse_iterator< my_container > { // defines [const_]iterator, begin() and end() };

and sequence::reverse_iterator will add [const_]reverse_iterator, rbegin() and rend() defined in terms of the others. The idea is to break up the string interface into its standard modules (capacity, iterators, etc.), with the flex_string-style class pulling in all of these. This allows a more flexible implementation and can be used by containers to implement the iterator component.

I think that is more of an interesting decomposition of container design in general, and should be scaled as such. Otherwise, you won't be able to reuse the components you define. Andrei

Martin wrote:

Wouldn't the flex_string be even more flexible if it accepted ranges in constructor, assignment etc. (same for fixed_string, const_string of course)

This is true. However, this may result in undesired behaviour. For example: template< typename String > void foo( String & str, const std::vector< typename String::char_type > & vec ) { str.assign( vec ); // uses assign( const RangeT & range ) } int main() { flex_string< char, SomeStringType > str1; std::string str2; std::vector< char > vec; // = "Meine Welt!" foo( str1, vec ); // ok: str1 = "Meine Welt!" foo( str2, vec ); // error - std::string does not have assign( const std::vector< char > & )! } This may change in either a TR or the next standard if/when ranges are added and incorporated into std::basic_string.

Then you could easily switch between different string types without the .c_str ()

This deepnds on whether begin(input), etc. would detect that flex_string has begin()/end() defined. Of course, the logic could be added to the begin( RangeT ) and end( RangeT ) definitions.

template <class RangeT> flex_string(const RangeT& input, const A& a = A()) : Storage(a) { assign(begin(input), end(input));

Couldn't this be assign( input ), since assing would have a RangeT variant.

}

Regards, Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam

Thanks very much for emailing me about flex_string. If you could also insert the following copyright notice, I'd be most grateful (beware of wrapped lines):

//////////////////////////////////////////////////////////////////////////////// // flex_string // Copyright (c) 2001 by Andrei Alexandrescu // Permission to use, copy, modify, distribute and sell this software for any // purpose is hereby granted without fee, provided that the above copyright // notice appear in all copies and that both that copyright notice and this // permission notice appear in supporting documentation. // The author makes no representations about the // suitability of this software for any purpose. It is provided "as is" // without express or implied warranty. ////////////////////////////////////////////////////////////////////////////////

Hold on a second: we've worked really hard over the last year to cut down on the number of licenses in Boost - and the normal requirement for new code now is that it be under the Boost Software License. Would you be willing to have the code appear under that license? In particular your terms above have a BSD style advertising clause, which I believe we've always forbidden Boost code from having (see http://www.boost.org/more/license_info.html). Regards, John Maddock.

Andrei Alexandrescu wrote:

...

Hold on a second: we've worked really hard over the last year to cut down on the number of licenses in Boost - and the normal requirement for new code now is that it be under the Boost Software License. Would you be willing to have the code appear under that license?

Yes, I agree.

Applied in CVS. Regards Hartmut

"Beman Dawes" <bdawes@acm.org> writes:

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:d5vuk8$fs8$1@sea.gmane.org...

...

...

Hold on a second: we've worked really hard over the last year to cut down on the number of licenses in Boost - and the normal requirement for new code now is that it be under the Boost Software License. Would you be willing to have the code appear under that license?

Yes, I agree.

Thanks, Andrei!

Yeah, um, thanks for being flex-ible. (sorry) punnilicious-ly y'rs, dave -- Dave Abrahams Boost Consulting www.boost-consulting.com