On Fri, Nov 16, 2012 at 8:50 AM, Peter Dimov <lists@pdimov.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
IMHO, I would think
typedef contiguous_range< char > string_ref; typedef contiguous_range< char const > string_cref;
would be better, ...
In what ways would it be better?
For one, it would provide a single implementation of a contiguous range of char, char const, unsigned char, unsigned char const, wchar_t, and wchar_t const. Secondly (and I haven't read the C++ proposal), I'm gathering one use case for string_ref is to provide a non-template API to accept or return a sequence of characters more generically than using a std::string but with no loss in runtime performance (here meaning no copying of the underlying characters). E.g., a function whose parameter is string_ref may accept a std::string or a std::vector< char >, which I think is an improvement over a parameter of type std::string. But there's nothing inherently string-like about that design; this use case exists for other value types as well. I used this technique recently: A base class defined a virtual function with signature {virtual contiguous_range< foo > bar() const}, and the derived classes could optionally back their collection of foo's by either a C-array, a {boost,std}::array, a std::vector, or my_custom_dynamic_array. Lastly, and I don't know how big a deal this is, but one could write more tailored range algorithms for contiguous_ranges of POD types (using std::memcpy or std::memset, for example, which may produce more optimal code (?) than std::copy or std::fill, resp.). So I can see a plausible advantage in having a single template class abstracting contiguous ranges. That's just my thinking at the moment, I could be missing something. - Jeff