Topic: string_view(const charT* begin, const charT* end)
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sun, 25 Sep 2016 09:43:50 +0200
Raw View
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
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160925074350.GA29046%40noemi.
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Sun, 25 Sep 2016 10:45:55 +0200
Raw View
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
On Sun, Sep 25, 2016 at 9:43 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> 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
>
> --
> 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-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160925074350.GA29046%40noemi.
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknwi2GhwhJCHOM7Ew5ED_4QkLQf3BNMaBWNF3q9hYc8snA%40mail.gmail.com.
.
Author: Mikhail Maltsev <maltsevm@gmail.com>
Date: Sun, 25 Sep 2016 15:12:56 +0300
Raw View
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
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8dfc0a2b-b9b3-35d7-673e-f26401de70b6%40gmail.com.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 25 Sep 2016 14:14:27 -0500
Raw View
--001a11415d26fd927a053d59d143
Content-Type: text/plain; charset=UTF-8
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.
On Sun, Sep 25, 2016 at 2:43 AM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:
> 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
>
> --
> 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-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/20160925074350.GA29046%40noemi.
>
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK2zrS7b%2BfqpXwGVC4z0gG2WN6n1guPaWBFnwcg1iqkvg%40mail.gmail.com.
--001a11415d26fd927a053d59d143
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this a reasonable idea.=C2=A0 Its a special case o=
f the:<div><br></div><div><span class=3D"gmail-kw1" style=3D"line-height:1.=
1em;margin:0px;padding:0px;color:rgb(0,0,221);font-family:dejavusansmono,&q=
uot;dejavu sans mono",courier,monospace;font-size:12.8px;white-space:n=
owrap">template</span><span class=3D"gmail-sy1" style=3D"line-height:1.1em;=
margin:0px;padding:0px;color:rgb(0,0,128);font-family:dejavusansmono,"=
dejavu sans mono",courier,monospace;font-size:12.8px;white-space:nowra=
p"><</span><span style=3D"color:rgb(0,0,0);font-family:dejavusansmono,&q=
uot;dejavu sans mono",courier,monospace;font-size:12.8px;white-space:n=
owrap">=C2=A0</span><span class=3D"gmail-kw1" style=3D"line-height:1.1em;ma=
rgin:0px;padding:0px;color:rgb(0,0,221);font-family:dejavusansmono,"de=
javu sans mono",courier,monospace;font-size:12.8px;white-space:nowrap"=
>class</span><span style=3D"color:rgb(0,0,0);font-family:dejavusansmono,&qu=
ot;dejavu sans mono",courier,monospace;font-size:12.8px;white-space:no=
wrap">=C2=A0InputIt=C2=A0</span><span class=3D"gmail-sy1" style=3D"line-hei=
ght:1.1em;margin:0px;padding:0px;color:rgb(0,0,128);font-family:dejavusansm=
ono,"dejavu sans mono",courier,monospace;font-size:12.8px;white-s=
pace:nowrap">></span><br style=3D"color:rgb(0,0,0);font-family:dejavusan=
smono,"dejavu sans mono",courier,monospace;font-size:12.8px;white=
-space:nowrap"><p style=3D"margin:0px;line-height:1.1em;padding:0px;color:r=
gb(0,0,0);font-family:dejavusansmono,"dejavu sans mono",courier,m=
onospace;font-size:12.8px;white-space:nowrap">basic_string<span class=3D"gm=
ail-br0" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,=
0)">(</span>=C2=A0InputIt first, InputIt last,=C2=A0<br></p><span style=3D"=
color:rgb(0,0,0);font-family:dejavusansmono,"dejavu sans mono",co=
urier,monospace;font-size:12.8px;white-space:nowrap">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><span class=3D"gmail-kw4" style=3D"=
line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,255);font-family:dej=
avusansmono,"dejavu sans mono",courier,monospace;font-size:12.8px=
;white-space:nowrap">const</span><span style=3D"color:rgb(0,0,0);font-famil=
y:dejavusansmono,"dejavu sans mono",courier,monospace;font-size:1=
2.8px;white-space:nowrap">=C2=A0Allocator</span><span class=3D"gmail-sy3" s=
tyle=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,64);font-fam=
ily:dejavusansmono,"dejavu sans mono",courier,monospace;font-size=
:12.8px;white-space:nowrap">&</span><span style=3D"color:rgb(0,0,0);fon=
t-family:dejavusansmono,"dejavu sans mono",courier,monospace;font=
-size:12.8px;white-space:nowrap">=C2=A0alloc=C2=A0</span><span class=3D"gma=
il-sy1" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,128=
);font-family:dejavusansmono,"dejavu sans mono",courier,monospace=
;font-size:12.8px;white-space:nowrap">=3D</span><span style=3D"color:rgb(0,=
0,0);font-family:dejavusansmono,"dejavu sans mono",courier,monosp=
ace;font-size:12.8px;white-space:nowrap">=C2=A0Allocator</span><span class=
=3D"gmail-br0" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(=
0,128,0);font-family:dejavusansmono,"dejavu sans mono",courier,mo=
nospace;font-size:12.8px;white-space:nowrap">(</span><span class=3D"gmail-b=
r0" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,0);fo=
nt-family:dejavusansmono,"dejavu sans mono",courier,monospace;fon=
t-size:12.8px;white-space:nowrap">)</span><span style=3D"color:rgb(0,0,0);f=
ont-family:dejavusansmono,"dejavu sans mono",courier,monospace;fo=
nt-size:12.8px;white-space:nowrap">=C2=A0</span><span class=3D"gmail-br0" s=
tyle=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,0);font-fa=
mily:dejavusansmono,"dejavu sans mono",courier,monospace;font-siz=
e:12.8px;white-space:nowrap">)</span><span class=3D"gmail-sy4" style=3D"lin=
e-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,128);font-family:deja=
vusansmono,"dejavu sans mono",courier,monospace;font-size:12.8px;=
white-space:nowrap">;</span><br></div><div><span class=3D"gmail-sy4" style=
=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,128);font-fami=
ly:dejavusansmono,"dejavu sans mono",courier,monospace;font-size:=
12.8px;white-space:nowrap"><br></span></div><div>but we can't use that =
one in string_view for obvious reasons.<br></div><div><br></div><div>It als=
o doesn't represent an ABI break as it is a pure addition with a trivia=
l implementation.</div><div><br></div><div>I encourage you to write and sub=
mit a short proposal to LEWG.</div><div><span class=3D"gmail-sy4" style=3D"=
line-height:1.1em;margin:0px;padding:0px;color:rgb(0,128,128);font-family:d=
ejavusansmono,"dejavu sans mono",courier,monospace;font-size:12.8=
px;white-space:nowrap"><br></span></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Sun, Sep 25, 2016 at 2:43 AM, Magnus Fromre=
ide <span dir=3D"ltr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D=
"_blank">magfr@lysator.liu.se</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">Hello.<br>
<br>
I just noticed that there is no<br>
string_view(const charT* begin, const charT* end) constructor in the curren=
t<br>
version and I think it would be a useful addition to string_view.<br>
<br>
Now, this is admittedly a very trivial constructor:<br>
<br>
string_view(const charT* begin, const charT* end)<br>
=C2=A0 : string_view(begin, end - begin)<br>
{ }<br>
<br>
but I still think it has utility when one is working with ranges (in the<br=
>
old C++ sense) of char pointers, so could it be added to the standard?<br>
<br>
One should also note that it makes a string_view more similar to a string<b=
r>
and that fits well into the design of string_view.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/MF<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160925074350.GA29046%40noemi" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/msgid/std-<wbr>proposals/20160925074350.<wbr>GA29046%40noemi</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK2zrS7b%2BfqpXwGVC4z0gG2WN6n=
1guPaWBFnwcg1iqkvg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK2zr=
S7b%2BfqpXwGVC4z0gG2WN6n1guPaWBFnwcg1iqkvg%40mail.gmail.com</a>.<br />
--001a11415d26fd927a053d59d143--
.
Author: 3dw4rd@verizon.net
Date: Fri, 10 Mar 2017 14:34:28 -0800 (PST)
Raw View
------=_Part_1357_1352327014.1489185268254
Content-Type: multipart/alternative;
boundary="----=_Part_1358_253464570.1489185268254"
------=_Part_1358_253464570.1489185268254
Content-Type: text/plain; charset=UTF-8
> /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.
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f1752993-2e10-440a-9ec7-d825c841dc0a%40isocpp.org.
------=_Part_1358_253464570.1489185268254
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&=
gt; /Peter
<br>string_view used to be an experimental feature, so the rest of the libr=
ary could
<br>not depend on it. Now it can be changed. See
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p025=
4r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0254r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNEjWYVBlkX_aHs22Lyu_13Raq-u8g';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0254r0.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNEjWYVBlkX_aHs22Lyu_13Raq-u8g';return true;">http://=
www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0254r0.pdf</a>
<br>
<br>--=20
<br>Mikhail Maltsev
<br></blockquote><div><br>This seems almost like a DR.=C2=A0 But I'm no=
t a lawyer.<br>=C2=A0<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f1752993-2e10-440a-9ec7-d825c841dc0a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1752993-2e10-440a-9ec7-d825c841dc0a=
%40isocpp.org</a>.<br />
------=_Part_1358_253464570.1489185268254--
------=_Part_1357_1352327014.1489185268254--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sat, 11 Mar 2017 02:34:05 +0300
Raw View
On Sun, Sep 25, 2016 at 10:43 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> 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.
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.
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6DvxUKK-qn60xLhE4u4daGDrPkb_ZWjKfJ8Sh1Pxi9vmw%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Mar 2017 17:47:40 -0800 (PST)
Raw View
------=_Part_2323_525078727.1489196860789
Content-Type: multipart/alternative;
boundary="----=_Part_2324_1202085103.1489196860790"
------=_Part_2324_1202085103.1489196860790
Content-Type: text/plain; charset=UTF-8
On Friday, March 10, 2017 at 6:34:07 PM UTC-5, Andrey Semashev wrote:
>
> On Sun, Sep 25, 2016 at 10:43 AM, Magnus Fromreide <ma...@lysator.liu.se
> <javascript:>> wrote:
> > 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.
>
> 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.
>
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.
--
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-proposals@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.
------=_Part_2324_1202085103.1489196860790
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, March 10, 2017 at 6:34:07 PM UTC-5, And=
rey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Sep=
25, 2016 at 10:43 AM, Magnus Fromreide <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"b5lmGOCQDAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">ma...@lysator.liu.se</a>> wrote:
<br>> Hello.
<br>>
<br>> I just noticed that there is no
<br>> string_view(const charT* begin, const charT* end) constructor in t=
he current
<br>> version and I think it would be a useful addition to string_view.
<br>>
<br>> Now, this is admittedly a very trivial constructor:
<br>>
<br>> string_view(const charT* begin, const charT* end)
<br>> =C2=A0 : string_view(begin, end - begin)
<br>> { }
<br>>
<br>> but I still think it has utility when one is working with ranges (=
in the
<br>> old C++ sense) of char pointers, so could it be added to the stand=
ard?
<br>>
<br>> One should also note that it makes a string_view more similar to a=
string
<br>> and that fits well into the design of string_view.
<br>
<br>Although I can see the usefullness of the constructor (i've wanted =
to
<br>use it myself a few times), I think it undermines the requirement of
<br>contiguity of the string.
<br>
<br>=C2=A0 void foo(deque< char > const& chars)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 string_view str{ &chars[0], &chars[10] };
<br>=C2=A0 }
<br>
<br>You could say the same kind of misuse is still possible with passing
<br>length as the second argument, but pointer + length traditionally
<br>means contiguous storage while two iterators (even if pointers) not
<br>neccessarilly so.
<br></blockquote><div><br>By that logic, all of the `to_chars` and `from_ch=
ars` functions are wrong too. After all, they deal in pointer ranges, not p=
ointer+lengths.<br><br>Besides, with <i>all</i> iterator ranges, there is a=
n explicit requirement that the iterator pairs provided represent an actual=
range of the type represented by the iterators. If the iterators are conti=
guous iterators, then they must represent a contiguous range. The fact that=
it's possible to pass malformed arguments to a function isn't a go=
od reason not to have such a function.<br><br>Especially when iterator pair=
s are already a fundamental part of the C++ standard library.<br></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6fe42cb5-c10b-4f7c-abf2-bbdf39a6c950%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6fe42cb5-c10b-4f7c-abf2-bbdf39a6c950=
%40isocpp.org</a>.<br />
------=_Part_2324_1202085103.1489196860790--
------=_Part_2323_525078727.1489196860789--
.
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Fri, 10 Mar 2017 20:59:21 -0600
Raw View
--94eb2c0e61da3db37e054a6baa78
Content-Type: text/plain; charset=UTF-8
On Fri, Mar 10, 2017 at 7:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, March 10, 2017 at 6:34:07 PM UTC-5, Andrey Semashev wrote:
>>
>> On Sun, Sep 25, 2016 at 10:43 AM, Magnus Fromreide <ma...@lysator.liu.se>
>> wrote:
>> > 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.
>>
>> 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.
>>
>
> 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.
>
> --
> 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-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6fe42cb5-c10b-4f7c-abf2-bbdf39a6c950%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
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.
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSZ0vPeTNvK1qa3wfqcet7ytQHVJo%2BOV68AUpJWbU9Tmg%40mail.gmail.com.
--94eb2c0e61da3db37e054a6baa78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Mar 10, 2017 at 7:47 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Friday, March 10, 2017 at 6:34:07 PM UTC-5, Andrey Semashev wrote:<s=
pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Sep 25, 2016=
at 10:43 AM, Magnus Fromreide <<a rel=3D"nofollow">ma...@lysator.liu.se=
</a>> wrote:
<br>> Hello.
<br>>
<br>> I just noticed that there is no
<br>> string_view(const charT* begin, const charT* end) constructor in t=
he current
<br>> version and I think it would be a useful addition to string_view.
<br>>
<br>> Now, this is admittedly a very trivial constructor:
<br>>
<br>> string_view(const charT* begin, const charT* end)
<br>> =C2=A0 : string_view(begin, end - begin)
<br>> { }
<br>>
<br>> but I still think it has utility when one is working with ranges (=
in the
<br>> old C++ sense) of char pointers, so could it be added to the stand=
ard?
<br>>
<br>> One should also note that it makes a string_view more similar to a=
string
<br>> and that fits well into the design of string_view.
<br>
<br>Although I can see the usefullness of the constructor (i've wanted =
to
<br>use it myself a few times), I think it undermines the requirement of
<br>contiguity of the string.
<br>
<br>=C2=A0 void foo(deque< char > const& chars)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 string_view str{ &chars[0], &chars[10] };
<br>=C2=A0 }
<br>
<br>You could say the same kind of misuse is still possible with passing
<br>length as the second argument, but pointer + length traditionally
<br>means contiguous storage while two iterators (even if pointers) not
<br>neccessarilly so.
<br></blockquote></span><div><br>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.<br><br>Besides, with <i>all</i> iterator ranges, the=
re is an explicit requirement that the iterator pairs provided represent an=
actual range of the type represented by the iterators. If the iterators ar=
e contiguous iterators, then they must represent a contiguous range. The fa=
ct that it's possible to pass malformed arguments to a function isn'=
;t a good reason not to have such a function.<br><br>Especially when iterat=
or pairs are already a fundamental part of the C++ standard library.<br></d=
iv></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6fe42cb5-c10b-4f7c-abf2-bbdf39a6c950%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6fe4=
2cb5-c10b-4f7c-<wbr>abf2-bbdf39a6c950%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">I realize this probably isn't a super helpful comment=
but in my own codebase I've given up on making a clear distinction bet=
ween 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 strin=
g_view string_span variations. Anyways, as you could assume from that state=
ment, 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.</=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSZ0vPeTNvK1qa3wfqcet7ytQHVJo=
%2BOV68AUpJWbU9Tmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSZ0v=
PeTNvK1qa3wfqcet7ytQHVJo%2BOV68AUpJWbU9Tmg%40mail.gmail.com</a>.<br />
--94eb2c0e61da3db37e054a6baa78--
.