From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-05-11 10:39:43
Andrei Alexandrescu 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.
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).
 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.
 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.
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
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
This could be extended to support common implementations for container
methods (e.g. back()/front() in terms of begin() and end()). The idea behind
this is for the classes as a whole to behave like iterator_facade.
Reece Haston Dunn
Software Engineer, Sophos
Sophos - protecting businesses against viruses and spam
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk