The fixed_string is already in the review schedule and a proposal for immutable strings was published recently. Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library. That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.
Martin <adrianm@touchdown.se> wrote:
The fixed_string is already in the review schedule and a proposal for immutable strings was published recently.
Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library.
That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.
I think that would be great to make the strings to know each other. Could you please provide a link to fixed_string docs and code? -- Maxim Yegorushkin
Maxim Yegorushkin wrote:
Martin <adrianm@touchdown.se> wrote:
The fixed_string is already in the review schedule and a proposal for immutable strings was published recently.
Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library.
Sure. I am using a modified version of flex_string to implement fixed_string, so reviewing both (and also immutable strings) would be a good idea.
That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.
Sure. We could maybe also consider the copy-on-write string storage class, etc. as well as flex_string.
I think that would be great to make the strings to know each other. Could you please provide a link to fixed_string docs and code?
It is in the boost sandbox (boost-sandbox/boost/fixed_string for the code and boost-sandbox/libs/fixed_string for the docs, examples and tests). The tests contain a complete minimal functionality test for the std::string interface. This checks both boost::fixed_string and boost::detail::basic_string_impl (that is a version of flex_string that incorporates some updates like using boost::reverse_iterator). I am willing to contribute these changes to a boost version of flex_string. Regards, Reece
Reece Dunn <msclrhd@hotmail.com> wrote:
Sure. I am using a modified version of flex_string to implement fixed_string, so reviewing both (and also immutable strings) would be a good idea.
I have a comment regarding the code of basic_string_impl. In its member functions it uses unqualified names of base class's functions. Like this: template< class Base, class ErrorPolicy = noerror_string_policy > class basic_string_impl: public Base { // ... inline const_iterator begin() const { return( begin_()); } // ... } On a conforming compiler this code won't compile, because the first phase of name lookup never considers argument dependent base classes for unqualified names (while the second phase doing ADL only). I don't have a gcc 3.4, which does two-phase name lookup, to check, but I believe it won't compile it. I advise using qualified base class's function names by prefixing them with this-> or, better, with this->Base:: because in this case you won't have to mangle base class's function names with _ suffix. -- Maxim Yegorushkin
Releated to this I just remembered this handy little helper string. parm_string: http://lists.boost.org/MailArchives/boost/msg59819.php Just an idea, perhaps this is already possible using const/fixed/flex_string et al? // Fredrik Blomqvist Martin wrote:
The fixed_string is already in the review schedule and a proposal for immutable strings was published recently.
Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library.
That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.
Fredrik Blomqvist <fredrik_blomqvist@home.se> wrote:
Releated to this I just remembered this handy little helper string. parm_string: http://lists.boost.org/MailArchives/boost/msg59819.php
Just an idea, perhaps this is already possible using const/fixed/flex_string et al?
// Fredrik Blomqvist
const_string<> does it. It allows for reference semantics when the string constructor's argument is not copied but referenced. -- Maxim Yegorushkin
participants (5)
-
Fredrik Blomqvist -
Hartmut Kaiser -
Martin -
Maxim Yegorushkin -
Reece Dunn