string_view(const charT* begin, const charT* end)

[Magnus Fromreide]

Hello.

I just noticed that there is no
string_view(const charT* begin, const charT* end) constructor in the current
version and I think it would be a useful addition to string_view.

Now, this is admittedly a very trivial constructor:

string_view(const charT* begin, const charT* end)
: string_view(begin, end - begin)
{ }

but I still think it has utility when one is working with ranges (in the
old C++ sense) of char pointers, so could it be added to the standard?

One should also note that it makes a string_view more similar to a string
and that fits well into the design of string_view.

/MF

[Peter Koch Larsen]

I do not know how many times I have used your proposed constructor
just to be informed by the compiler that it is not there. Thus, I am
in favour your proposal.
Also, I have wanted to create as std::string from a string_view, and
that part could also be made easier. Any reason there is not an
(explicit) std::string constructor from a string_view?

/Peter

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160925074350.GA29046%40noemi.

[Mikhail Maltsev]

On 25.09.2016 11:45, Peter Koch Larsen wrote:
> Also, I have wanted to create as std::string from a string_view, and
> that part could also be made easier. Any reason there is not an
> (explicit) std::string constructor from a string_view?
>
> /Peter

string_view used to be an experimental feature, so the rest of the library could
not depend on it. Now it can be changed. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0254r0.pdf

--
Mikhail Maltsev

[Andrew Tomazos]

I think this a reasonable idea.  Its a special case of the:

template< class InputIt >

basic_string( InputIt first, InputIt last, 

              const Allocator& alloc = Allocator() );

but we can't use that one in string_view for obvious reasons.

It also doesn't represent an ABI break as it is a pure addition with a trivial implementation.

I encourage you to write and submit a short proposal to LEWG.

/MF

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

[3dw...@verizon.net]

> /Peter
string_view used to be an experimental feature, so the rest of the library could
not depend on it. Now it can be changed. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0254r0.pdf

--
Mikhail Maltsev

This seems almost like a DR.  But I'm not a lawyer.
 

[Andrey Semashev]

Although I can see the usefullness of the constructor (i've wanted to
use it myself a few times), I think it undermines the requirement of
contiguity of the string.

void foo(deque< char > const& chars)
{
string_view str{ &chars[0], &chars[10] };
}

You could say the same kind of misuse is still possible with passing
length as the second argument, but pointer + length traditionally
means contiguous storage while two iterators (even if pointers) not
neccessarilly so.

[Nicol Bolas]

By that logic, all of the `to_chars` and `from_chars` functions are wrong too. After all, they deal in pointer ranges, not pointer+lengths.

Besides, with all iterator ranges, there is an explicit requirement that the iterator pairs provided represent an actual range of the type represented by the iterators. If the iterators are contiguous iterators, then they must represent a contiguous range. The fact that it's possible to pass malformed arguments to a function isn't a good reason not to have such a function.

Especially when iterator pairs are already a fundamental part of the C++ standard library.

[Brittany Friedman]

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6fe42cb5-c10b-4f7c-abf2-bbdf39a6c950%40isocpp.org.

I realize this probably isn't a super helpful comment but in my own codebase I've given up on making a clear distinction between vectors and strings. It's just not really that valuable. I have a function for converting a null-terminated pointer to a span and a function for null-terminating a vector. No need for a string class or a zoo of string_view string_span variations. Anyways, as you could assume from that statement, I obviously think a string view from (begin,end) should be allowed as it seems to me that it's really "all the same" in the end.