Additional string_ref constructors

[Domagoj Šarić]

From:

• iterator_range<Char const *>
• std::vector<Char>
• pair of iterators

[Marshall Clow]

A string_re refers to a contiguous sequence of characters.

An iterator_range is not contiguous. Nor is, in general, a pair of iterators.

The contents of a vector<char> are, but you can make a string_ref easily thus: string_ref sr(&*v.begin(), v.size());

I don't see a compelling need here. If you have examples, (things that you want to do that are awkward/impossible w/o these constructors) please tell me about them.

[anonymous]

I couldn't use string_ref as return value of boost/algorithm/split.hpp because string_ref doesn't provide [b, e) style constructor. This is only annoying thing I can think of current string_ref. Other than that I'm using it everywhere.

[Marshall Clow]

if you have two iterators that you know point to a contiguous sequence in memory you can create a string_ref

thus: string_ref sr(&*b, std::distance(b, e));

or: string_ref sr(&*b, e - b);

[vladimir.krivopalov@…]

Hi,

It seems that string_ref really lacks these constructors as cannot work with boost::algorithm::split (a widely used one) without them although std::string which boost::string_ref aims to substitute in such cases fits the requirements of this algorithm perfectly.

You're right about that pair of iterators doesn't necessarily point to a contiguous storage, but this may be a requirement for this constructor to follow. Consider the existing constructor: string_ref(CharT* str); it crashes if you pass NULL/nullptr to it, so assumes that the input parameter is non-NULL. But this is not enforced (although here it is even possible to check that).

The same could apply for the range-based constructor which would allow for range-based algorithms to chime in.