2012/11/16 Yanchenko Maxim <maximyanchenko@yandex.ru>:
Marshall. low <mclow.lists. at> gmail.com> writes:
Please let me know what you think!
As probably everyone, we have our own device for this. Here are some points and experience we gathered.
1. This class is essentially just an iterator_ range<char*> (modulo template for const/wchar_t), so it should either inherit from it or have corresponding converting ctors/operators. In this sense Olaf/Gennadiy's remarks are pretty valid. OTOH size is needed very frequently and having it precomputed is a good thing, so conversion approach seems to be better (but then we lose passing by reference as iterator_range, type_traits etc). I'm not sure what's more important.
+1 for having corresponding explicit converting ctors/operators.
2. Given the above, the name is misleading as it's not a reference to std::string. We use name char_range.
Better then other names, but at first glance it is not clear, that char_range can be used as string.
3. It's worth having a static constructor 'literal' (templated with size) to construct char_ranges from literals - as the compiler knows their size in compile time (minus zero terminator). It can be a constexpr too. Same manner - static function 'from_array', embrasing an array of chars in whole, assuming there is no zero terminator - useful for working with structures representing messages in char-based protocols with fixed-width fields.
Instead of 'literal' I'd propose a following constructor: template <size_type N> explicit string_ref(const Char (&str)[N]); As I know, lots of people are unhappy with current design of std::basic_string. They think that it has too many member functions in it. If those functions were also implemented as free, more containers would be able to reuse them (they can be reused by basic_string implementation in Boost.Containers, by string_ref implementation). May be authors of Boost.StringAlgo, Boost.Container, Boost.StringRef cooperate for better code reuse? -- Best regards, Antony Polukhin