Boost C++ Libraries: Ticket #9287: Additional string_ref constructors

owner, status changed

Marshall Clow — Tue, 22 Oct 2013 12:29:23 GMT

owner changed from No-Maintainer to Marshall Clow
status new → assigned

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 — Mon, 29 Dec 2014 18:27:19 GMT

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 — Tue, 30 Dec 2014 17:09:59 GMT

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@… — Tue, 12 May 2015 00:57:48 GMT

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.