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 16:20:36

On Fri, Nov 16, 2012 at 10:16 AM, Peter Dimov <lists_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
>
>  ... I haven't read the C++ proposal ...
>>
>
> http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2012/**n3442.html
>

>
>  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.
>>
>
> It does.
>
>  But there's nothing inherently string-like about that design;
>>
>
> There are a number of very string-like things about the design.
>

We're talking about 2 different designs. The way Marshall had originally
phrased it (or, at least, how I originally read it), it was just a wrapper
around a pair of char*s, or a char* and a std::size_t, not much more than
that.

N3442, on the other hand, is entirely specific to strings, but some of the
motivations of N3442 seem questionable (specifically, copying and
perpetuating the already bloated interface of std::string; I can see where
this is desirable, but I can also see where it's undesirable). If we
separate the string-specific stuff out as free functions, then what's left
is a component that offers a level of genericity without templates and
without sacrificing performance. I gathered Marshall had proposed this
primarily in order to make the StringAlgorithms API more flexible without
loss of performance.

Actually, now that I think about it, contiguous_range<T> ==
iterator_range<T*>, AFAICT. Maybe iterator_range<T*> might want some member
functions added for conversion to/from other contiguous ranges, and maybe
there are some other interface tweaks one can make specific for pointers.

 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.
>>
>
> To do this, you should accept an arbitrary Range and check a trait
> (is_contiguous), not hardcode contiguous_range<> (for instance, std::vector
> isn't contiguous_range<>, bit it is a contiguous range).
>

True; indeed, I like Yakov's suggestion of a contiguous_traversal_tag
(sorry I'm slightly modifying the suggestion to use boost::traversal_tags
rather than std::iterator_tags).

- Jeff