Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-16 12:12:11

On Fri, Nov 16, 2012 at 8:50 AM, Peter Dimov <lists_at_[hidden]> 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