On Fri, Nov 16, 2012 at 10:16 AM, Peter Dimov <lists@pdimov.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
... I haven't read the C++ proposal ...
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