On Fri, Nov 16, 2012 at 8:16 PM, Peter Dimov <lists@pdimov.com> wrote:
[...]
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).
I would attack this problem in a different way. There should be a contiguous_iterator_tag : random_access_iterator_tag in the standard, then we get two things for free: * Paragraphs ?.2.2/3 are not longer relevant. We will be able to construct a string_ref from any Range of contiguous_iterators. * The standard library implementation can specialize the standard algorithms for std::copy to use the optimized memcpy whenever a contiguous_iterators to a POD is given. contiguous_range<> would be essentially an iterator_range<> with contiguous_iterators. -- Yakov