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