Topic: Marking more std::string_view members noexcept
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Sep 2016 15:21:18 +0300
Raw View
Hi,
I'm looking at string_view interface definition in N4606 and wondering
why so many members are not marked noexcept? For example, these
constructors:
constexpr basic_string_view(const charT* str);
constexpr basic_string_view(const charT* str, size_type len);
Assuming that the input string is not a constant expression, the first
constructor would call an equivalent of strlen(str), which in 99% is a
no-throw operation. Why not mark it
"noexcept(noexcept(traits::length(str))"? The second constructor does
not even need that and could be simply noexcept.
I'm most interested in constructors, but other members like operator[],
front(), back(), substr(), compare() also don't seem to need to ever
throw, yet they are not marked noexcept.
Is there a reason for these omissions?
Also, why there is no obvious constructor from basic_string?
Thanks.
--
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/3d03cd7d-2177-98fd-408d-f74b1f6a8552%40gmail.com.
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 27 Sep 2016 19:47:00 +0200
Raw View
2016-09-27 14:21 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> Hi,
>
> I'm looking at string_view interface definition in N4606 and wondering why
> so many members are not marked noexcept? For example, these constructors:
>
> constexpr basic_string_view(const charT* str);
> constexpr basic_string_view(const charT* str, size_type len);
>
> Assuming that the input string is not a constant expression, the first
> constructor would call an equivalent of strlen(str), which in 99% is a
> no-throw operation. Why not mark it
> "noexcept(noexcept(traits::length(str))"? The second constructor does not
> even need that and could be simply noexcept.
>
> I'm most interested in constructors, but other members like operator[],
> front(), back(), substr(), compare() also don't seem to need to ever throw,
> yet they are not marked noexcept.
>
> Is there a reason for these omissions?
This is so, because these functions have a narrow contract. The
current guideline for LWG was described by this proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf
> Also, why there is no obvious constructor from basic_string?
Which one in particular is in your mind?
Thanks,
- Daniel
--
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/CAGNvRgBSk47UXuzh_jm_Yr2pBCM5NYSZ8kqVjwLyWsm-4r6ozw%40mail.gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 27 Sep 2016 12:47:13 -0500
Raw View
--001a113d2f5214b208053d80d887
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 27, 2016 at 7:21 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> Hi,
>
> I'm looking at string_view interface definition in N4606 and wondering why
> so many members are not marked noexcept? For example, these constructors:
>
> constexpr basic_string_view(const charT* str);
> constexpr basic_string_view(const charT* str, size_type len);
>
> Assuming that the input string is not a constant expression, the first
> constructor would call an equivalent of strlen(str), which in 99% is a
> no-throw operation. Why not mark it "noexcept(noexcept(traits::length(str))"?
> The second constructor does not even need that and could be simply noexcept.
>
> I'm most interested in constructors, but other members like operator[],
> front(), back(), substr(), compare() also don't seem to need to ever throw,
> yet they are not marked noexcept.
> Is there a reason for these omissions?
>
The usual reason: they are narrow contracts with preconditions. See n3279
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf>.
> Also, why there is no obvious constructor from basic_string?
>
See p0254r2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0254r2.pdf>.
Note: you can still construct a basic_string_view from a basic_string
via basic_string::operator
basic_string_view.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BPEcOT0tdSBEkZRxDWB%2BKoEtkq2DJA_3hu7DgUeTU7M8w%40mail.gmail.com.
--001a113d2f5214b208053d80d887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Sep 27, 2016 at 7:21 AM, Andrey Semashev <span dir=
=3D"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm looking at string_view interface definition in N4606 and wondering =
why so many members are not marked noexcept? For example, these constructor=
s:<br>
<br>
=C2=A0 constexpr basic_string_view(const charT* str);<br>
=C2=A0 constexpr basic_string_view(const charT* str, size_type len);<br>
<br>
Assuming that the input string is not a constant expression, the first cons=
tructor would call an equivalent of strlen(str), which in 99% is a no-throw=
operation. Why not mark it "noexcept(noexcept(traits::len<wbr>gth(str=
))"? The second constructor does not even need that and could be simpl=
y noexcept.<br>
<br>
I'm most interested in constructors, but other members like operator[],=
front(), back(), substr(), compare() also don't seem to need to ever t=
hrow, yet they are not marked noexcept.=C2=A0</blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
Is there a reason for these omissions?<br></blockquote><div><br></div><div>=
The usual reason: =C2=A0they are narrow contracts with preconditions.=C2=A0=
See=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
1/n3279.pdf">n3279</a>.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Also, why there is no obvious constructor from basic_string?<br></blockqu=
ote><div><br></div><div>See <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2016/p0254r2.pdf">p0254r2</a>.=C2=A0 Note: =C2=A0you can sti=
ll construct a <font face=3D"monospace, monospace">basic_string_view</font>=
from a <font face=3D"monospace, monospace">basic_string</font> via <font f=
ace=3D"monospace, monospace">basic_string::operator basic_string_view</font=
>.=C2=A0</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D=
"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &=
quot;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404=
</div></div></div></div></div>
</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/CAGg_6%2BPEcOT0tdSBEkZRxDWB%2BKoEtkq2=
DJA_3hu7DgUeTU7M8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPEcO=
T0tdSBEkZRxDWB%2BKoEtkq2DJA_3hu7DgUeTU7M8w%40mail.gmail.com</a>.<br />
--001a113d2f5214b208053d80d887--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Sep 2016 21:24:44 +0300
Raw View
On 09/27/16 20:47, Daniel Kr=C3=BCgler wrote:
> 2016-09-27 14:21 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
>> Hi,
>>
>> I'm looking at string_view interface definition in N4606 and wondering w=
hy
>> so many members are not marked noexcept? For example, these constructors=
:
>>
>> constexpr basic_string_view(const charT* str);
>> constexpr basic_string_view(const charT* str, size_type len);
>>
>> Assuming that the input string is not a constant expression, the first
>> constructor would call an equivalent of strlen(str), which in 99% is a
>> no-throw operation. Why not mark it
>> "noexcept(noexcept(traits::length(str))"? The second constructor does no=
t
>> even need that and could be simply noexcept.
>>
>> I'm most interested in constructors, but other members like operator[],
>> front(), back(), substr(), compare() also don't seem to need to ever thr=
ow,
>> yet they are not marked noexcept.
>>
>> Is there a reason for these omissions?
>
> This is so, because these functions have a narrow contract. The
> current guideline for LWG was described by this proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf
I see. Still, it feels wrong that functions that you never expect to=20
throw are not marked noexcept. When you write non-throwing code you=20
would look at the functions your code calls and not seeing noexcept=20
there immediately throws a red flag.
>> Also, why there is no obvious constructor from basic_string?
>
> Which one in particular is in your mind?
I was thinking of "basic_string_view(basic_string const&)", but Nevin=20
already pointed me to p0254r2 and I can see there is a conversion=20
operator in basic_string instead. This looks like a very reasonable=20
solution.
--=20
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 e=
mail 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/af89c375-0437-4092-cfc7-d93eafbf969e%40gmail.com=
..
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 27 Sep 2016 13:42:02 -0700 (PDT)
Raw View
------=_Part_1021_1942696835.1475008922846
Content-Type: multipart/alternative;
boundary="----=_Part_1022_1898984703.1475008922847"
------=_Part_1022_1898984703.1475008922847
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote:
>
> On 09/27/16 20:47, Daniel Kr=C3=BCgler wrote:=20
> > 2016-09-27 14:21 GMT+02:00 Andrey Semashev <andrey....@gmail.com=20
> <javascript:>>:=20
> >> Hi,=20
> >>=20
> >> I'm looking at string_view interface definition in N4606 and wondering=
=20
> why=20
> >> so many members are not marked noexcept? For example, these=20
> constructors:=20
> >>=20
> >> constexpr basic_string_view(const charT* str);=20
> >> constexpr basic_string_view(const charT* str, size_type len);=20
> >>=20
> >> Assuming that the input string is not a constant expression, the first=
=20
> >> constructor would call an equivalent of strlen(str), which in 99% is a=
=20
> >> no-throw operation. Why not mark it=20
> >> "noexcept(noexcept(traits::length(str))"? The second constructor does=
=20
> not=20
> >> even need that and could be simply noexcept.=20
> >>=20
> >> I'm most interested in constructors, but other members like operator[]=
,=20
> >> front(), back(), substr(), compare() also don't seem to need to ever=
=20
> throw,=20
> >> yet they are not marked noexcept.=20
> >>=20
> >> Is there a reason for these omissions?=20
> >=20
> > This is so, because these functions have a narrow contract. The=20
> > current guideline for LWG was described by this proposal:=20
> >=20
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf=20
>
> I see. Still, it feels wrong that functions that you never expect to=20
> throw are not marked noexcept. When you write non-throwing code you=20
> would look at the functions your code calls and not seeing noexcept=20
> there immediately throws a red flag.
>
I believe the point is that it *shouldn't* "throw a red flag". This is a=20
matter of simple practicality.
C API functions cannot throw exceptions, but they equally are incapable of=
=20
being marked `noexcept`. C++ libraries written before C++11 will not have=
=20
non-throwing functions marked `noexcept`. And many C++ libraries even=20
post-11 don't rigidly mark every non-throwing function as `noexcept`.
At the end of the day, C++ programmers cannot in general assume that every=
=20
function not marked `noexcept` is a throwing function.
--=20
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 e=
mail 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/2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4%40isocpp.or=
g.
------=_Part_1022_1898984703.1475008922847
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4=
, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 09/=
27/16 20:47, Daniel Kr=C3=BCgler wrote:
<br>> 2016-09-27 14:21 GMT+02:00 Andrey Semashev <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"k9hY79sRBQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">andrey....@gmail.com</a=
>>:
<br>>> Hi,
<br>>>
<br>>> I'm looking at string_view interface definition in N4606 a=
nd wondering why
<br>>> so many members are not marked noexcept? For example, these co=
nstructors:
<br>>>
<br>>> =C2=A0 constexpr basic_string_view(const charT* str);
<br>>> =C2=A0 constexpr basic_string_view(const charT* str, size_type=
len);
<br>>>
<br>>> Assuming that the input string is not a constant expression, t=
he first
<br>>> constructor would call an equivalent of strlen(str), which in =
99% is a
<br>>> no-throw operation. Why not mark it
<br>>> "noexcept(noexcept(traits::<wbr>length(str))"? The s=
econd constructor does not
<br>>> even need that and could be simply noexcept.
<br>>>
<br>>> I'm most interested in constructors, but other members lik=
e operator[],
<br>>> front(), back(), substr(), compare() also don't seem to ne=
ed to ever throw,
<br>>> yet they are not marked noexcept.
<br>>>
<br>>> Is there a reason for these omissions?
<br>>
<br>> This is so, because these functions have a narrow contract. The
<br>> current guideline for LWG was described by this proposal:
<br>>
<br>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011=
/n3279.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw';return true;">http://w=
ww.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2011/<wbr>n3279.pdf</a>
<br>
<br>I see. Still, it feels wrong that functions that you never expect to=20
<br>throw are not marked noexcept. When you write non-throwing code you=20
<br>would look at the functions your code calls and not seeing noexcept=20
<br>there immediately throws a red flag.<br></blockquote><div><br>I believe=
the point is that it <i>shouldn't</i> "throw a red flag". Th=
is is a matter of simple practicality.<br><br>C API functions cannot throw =
exceptions, but they equally are incapable of being marked `noexcept`. C++ =
libraries written before C++11 will not have non-throwing functions marked =
`noexcept`. And many C++ libraries even post-11 don't rigidly mark ever=
y non-throwing function as `noexcept`.<br><br>At the end of the day, C++ pr=
ogrammers cannot in general assume that every function not marked `noexcept=
` is a throwing function.<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/2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4=
%40isocpp.org</a>.<br />
------=_Part_1022_1898984703.1475008922847--
------=_Part_1021_1942696835.1475008922846--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Sep 2016 23:59:45 +0300
Raw View
On 09/27/16 23:42, Nicol Bolas wrote:
>
> On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote:
>
> Still, it feels wrong that functions that you never expect to
> throw are not marked noexcept. When you write non-throwing code you
> would look at the functions your code calls and not seeing noexcept
> there immediately throws a red flag.
>
> I believe the point is that it /shouldn't/ "throw a red flag". This is a
> matter of simple practicality.
>
> C API functions cannot throw exceptions, but they equally are incapable
> of being marked `noexcept`. C++ libraries written before C++11 will not
> have non-throwing functions marked `noexcept`. And many C++ libraries
> even post-11 don't rigidly mark every non-throwing function as `noexcept`.
>
> At the end of the day, C++ programmers cannot in general assume that
> every function not marked `noexcept` is a throwing function.
That is true. But if one really wants to rely on such function in a
non-throwing code, he would have to inspect its implementation or rely
on documentation stating it won't throw. C functions (i.e. the ones that
are declared extern "C") are not a problem in this respect as they
implicitly never throw.
What I'm saying is that yes, you can use unmarked functions, but it
entails more cost on you and is more fragile (what if the function
starts to throw at some point in the future?) While by simply marking
the function you can remove that cost and make the no-throw guarantee
part of the interface.
--
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/da4a8fb7-246b-f19c-3f50-7bb5f318f1a4%40gmail.com.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 27 Sep 2016 15:52:46 -0700 (PDT)
Raw View
------=_Part_2996_946260890.1475016766678
Content-Type: text/plain; charset=UTF-8
On Tuesday, 27 September 2016 21:59:49 UTC+1, Andrey Semashev wrote:
> On 09/27/16 23:42, Nicol Bolas wrote:
> >
> > On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote:
> >
> > Still, it feels wrong that functions that you never expect to
> > throw are not marked noexcept. When you write non-throwing code you
> > would look at the functions your code calls and not seeing noexcept
> > there immediately throws a red flag.
> >
> > I believe the point is that it /shouldn't/ "throw a red flag". This is a
> > matter of simple practicality.
> >
> > C API functions cannot throw exceptions, but they equally are incapable
> > of being marked `noexcept`. C++ libraries written before C++11 will not
> > have non-throwing functions marked `noexcept`. And many C++ libraries
> > even post-11 don't rigidly mark every non-throwing function as `noexcept`.
> >
> > At the end of the day, C++ programmers cannot in general assume that
> > every function not marked `noexcept` is a throwing function.
>
> That is true. But if one really wants to rely on such function in a
> non-throwing code, he would have to inspect its implementation or rely
> on documentation stating it won't throw. C functions (i.e. the ones that
> are declared extern "C") are not a problem in this respect as they
> implicitly never throw.
>
> What I'm saying is that yes, you can use unmarked functions, but it
> entails more cost on you and is more fragile (what if the function
> starts to throw at some point in the future?) While by simply marking
> the function you can remove that cost and make the no-throw guarantee
> part of the interface.
It is intentional that the function might start to throw in the future, or at least in certain compilation modes. A high quality implementation might well throw from front() called on an empty string_view when built in debug mode.
noexcept is properly reserved for functions that have no preconditions, or where throwing would never be an appropriate reaction to precondition violation.
--
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/0574ad73-0d36-47c0-9e47-79e234cc6708%40isocpp.org.
------=_Part_2996_946260890.1475016766678--
.
Author: pavel.kryukov@phystech.edu
Date: Wed, 25 Oct 2017 13:07:45 -0700 (PDT)
Raw View
------=_Part_11791_570656710.1508962066028
Content-Type: multipart/alternative;
boundary="----=_Part_11792_1188707188.1508962066028"
------=_Part_11792_1188707188.1508962066028
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi
If there was a ctor from array reference, would it be noexcept?
template<size_t N>
constexpr basic_string_view(const charT(&str)[N]) noexcept;
Of course, you may do reinterpret_cast and pass something wrong to it, but=
=20
it would be programmer's responsibility.
Thanks,
--
Pavel Kryukov
=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 28 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=
=80=D1=8F 2016 =D0=B3., 1:52:47 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Edward Catmur=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Tuesday, 27 September 2016 21:59:49 UTC+1, Andrey Semashev wrote:
> > On 09/27/16 23:42, Nicol Bolas wrote:
> > >
> > > On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev=
=20
> wrote:
> > >
> > > Still, it feels wrong that functions that you never expect to
> > > throw are not marked noexcept. When you write non-throwing code y=
ou
> > > would look at the functions your code calls and not seeing noexce=
pt
> > > there immediately throws a red flag.
> > >
> > > I believe the point is that it /shouldn't/ "throw a red flag". This i=
s=20
> a
> > > matter of simple practicality.
> > >
> > > C API functions cannot throw exceptions, but they equally are incapab=
le
> > > of being marked `noexcept`. C++ libraries written before C++11 will n=
ot
> > > have non-throwing functions marked `noexcept`. And many C++ libraries
> > > even post-11 don't rigidly mark every non-throwing function as=20
> `noexcept`.
> > >
> > > At the end of the day, C++ programmers cannot in general assume that
> > > every function not marked `noexcept` is a throwing function.
> >=20
> > That is true. But if one really wants to rely on such function in a=20
> > non-throwing code, he would have to inspect its implementation or rely=
=20
> > on documentation stating it won't throw. C functions (i.e. the ones tha=
t=20
> > are declared extern "C") are not a problem in this respect as they=20
> > implicitly never throw.
> >=20
> > What I'm saying is that yes, you can use unmarked functions, but it=20
> > entails more cost on you and is more fragile (what if the function=20
> > starts to throw at some point in the future?) While by simply marking=
=20
> > the function you can remove that cost and make the no-throw guarantee=
=20
> > part of the interface.
>
> It is intentional that the function might start to throw in the future, o=
r=20
> at least in certain compilation modes. A high quality implementation migh=
t=20
> well throw from front() called on an empty string_view when built in debu=
g=20
> mode.=20
>
> noexcept is properly reserved for functions that have no preconditions, o=
r=20
> where throwing would never be an appropriate reaction to precondition=20
> violation.=20
>
>
--=20
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 e=
mail 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/79ff7517-9d44-4770-8124-a2a036a2e6be%40isocpp.or=
g.
------=_Part_11792_1188707188.1508962066028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<div><br></div><div>If there was a ctor from array refer=
ence, would it be noexcept?</div><div><br></div><div>template<size_t N&g=
t;</div><div>constexpr basic_string_view(const charT(&str)[N]) noexcept=
;</div><div><br></div><div>Of course, you may do reinterpret_cast and pass =
something wrong to it, but it would be programmer's responsibility.</di=
v><div><br></div><div>Thanks,</div><div>--</div><div>Pavel Kryukov</div><di=
v><br>=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 28 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2016 =D0=B3., 1:52:47 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Edward Catmur =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tu=
esday, 27 September 2016 21:59:49 UTC+1, Andrey Semashev =C2=A0wrote:<br>&g=
t; On 09/27/16 23:42, Nicol Bolas wrote:<br>> ><br>> > On Tuesd=
ay, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote:<br>> =
><br>> > =C2=A0 =C2=A0 Still, it feels wrong that functions that y=
ou never expect to<br>> > =C2=A0 =C2=A0 throw are not marked noexcept=
.. When you write non-throwing code you<br>> > =C2=A0 =C2=A0 would loo=
k at the functions your code calls and not seeing noexcept<br>> > =C2=
=A0 =C2=A0 there immediately throws a red flag.<br>> ><br>> > I=
believe the point is that it /shouldn't/ "throw a red flag".=
This is a<br>> > matter of simple practicality.<br>> ><br>>=
> C API functions cannot throw exceptions, but they equally are incapab=
le<br>> > of being marked `noexcept`. C++ libraries written before C+=
+11 will not<br>> > have non-throwing functions marked `noexcept`. An=
d many C++ libraries<br>> > even post-11 don't rigidly mark every=
non-throwing function as `noexcept`.<br>> ><br>> > At the end =
of the day, C++ programmers cannot in general assume that<br>> > ever=
y function not marked `noexcept` is a throwing function.<br>> <br>> T=
hat is true. But if one really wants to rely on such function in a <br>>=
non-throwing code, he would have to inspect its implementation or rely <br=
>> on documentation stating it won't throw. C functions (i.e. the on=
es that <br>> are declared extern "C") are not a problem in th=
is respect as they <br>> implicitly never throw.<br>> <br>> What I=
'm saying is that yes, you can use unmarked functions, but it <br>> =
entails more cost on you and is more fragile (what if the function <br>>=
starts to throw at some point in the future?) While by simply marking <br>=
> the function you can remove that cost and make the no-throw guarantee =
<br>> part of the interface.<p>It is intentional that the function might=
start to throw in the future, or at least in certain compilation modes. A =
high quality implementation might well throw from front() called on an empt=
y string_view when built in debug mode. </p><p>noexcept is properly reserve=
d for functions that have no preconditions, or where throwing would never b=
e an appropriate reaction to precondition violation. </p><p></p></blockquot=
e></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/79ff7517-9d44-4770-8124-a2a036a2e6be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79ff7517-9d44-4770-8124-a2a036a2e6be=
%40isocpp.org</a>.<br />
------=_Part_11792_1188707188.1508962066028--
------=_Part_11791_570656710.1508962066028--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 25 Oct 2017 16:02:33 -0500
Raw View
--089e082577e04dfcb2055c65626f
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 25, 2017 at 3:07 PM, <pavel.kryukov@phystech.edu> wrote:
> Hi
>
> If there was a ctor from array reference, would it be noexcept?
>
> template<size_t N>
> constexpr basic_string_view(const charT(&str)[N]) noexcept;
>
It hasn't been proposed, has it?
My guess would be no, since there is a precondition that str[N-1] == 0,
giving it a narrow contract.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BPv2BYcxMJ5aQ9uLb2qpgVZ3ThFjoWdKBNyZ4oNPm0A-A%40mail.gmail.com.
--089e082577e04dfcb2055c65626f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 25, 2017 at 3:07 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:pavel.kryukov@phystech.edu" target=3D"_blank">pavel.kryukov=
@phystech.edu</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi<div><b=
r></div><div>If there was a ctor from array reference, would it be noexcept=
?</div><div><br></div><div>template<size_t N></div><div>constexpr bas=
ic_string_view(const charT(&str)[N]) noexcept;</div></div></blockquote>=
<div><br></div><div>It hasn't been proposed, has it?</div><div><br></di=
v><div>My guess would be no, since there is a precondition that str[N-1] =
=3D=3D 0, giving it a narrow contract.</div></div>-- <br><div class=3D"gmai=
l_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</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/CAGg_6%2BPv2BYcxMJ5aQ9uLb2qpgVZ3ThFjo=
WdKBNyZ4oNPm0A-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPv2BYc=
xMJ5aQ9uLb2qpgVZ3ThFjoWdKBNyZ4oNPm0A-A%40mail.gmail.com</a>.<br />
--089e082577e04dfcb2055c65626f--
.
Author: =?koi8-r?B?8MHXxcwg6cfP0sXXyd4g69LAy8/X?= <pavel.kryukov@phystech.edu>
Date: Thu, 26 Oct 2017 00:16:42 +0300
Raw View
--Apple-Mail-A0855A3F-CC91-49F6-8BFC-54DCF32ADA1A
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> It hasn't been proposed, has it?
I=E2=80=99m not aware of that. If it is a narrow contract, I don=E2=80=99t =
see much value in such proposal. We already have a narrow contract `basic_s=
tring_view(const charT*)` ctor, and a noexcept `operator=E2=80=9D=E2=80=9Ds=
v`.
--
Pavel
> 26 =D0=BE=D0=BA=D1=82. 2017 =D0=B3., =D0=B2 0:02, Nevin Liber <nevin@evil=
overlord.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
>> On Wed, Oct 25, 2017 at 3:07 PM, <pavel.kryukov@phystech.edu> wrote:
>> Hi
>>=20
>> If there was a ctor from array reference, would it be noexcept?
>>=20
>> template<size_t N>
>> constexpr basic_string_view(const charT(&str)[N]) noexcept;
>=20
> It hasn't been proposed, has it?
>=20
> My guess would be no, since there is a precondition that str[N-1] =3D=3D =
0, giving it a narrow contract.
> --=20
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/FaBXmXBWHHI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/CAGg_6%2BPv2BYcxMJ5aQ9uLb2qpgVZ3ThFjoWdKBNyZ4o=
NPm0A-A%40mail.gmail.com.
--=20
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 e=
mail 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/89333EED-6CC2-43D5-9EFB-C2F59E5819A2%40phystech.=
edu.
--Apple-Mail-A0855A3F-CC91-49F6-8BFC-54DCF32ADA1A
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto">> <span style=3D"background-color: r=
gba(255, 255, 255, 0);">It hasn't been proposed, has it?</span><div><br></d=
iv><div>I=E2=80=99m not aware of that. If it is a narrow contract, I don=E2=
=80=99t see much value in such proposal. We already have a narrow contract =
`basic_string_view(const charT*)` ctor, and a noexcept `operator=E2=80=9D=
=E2=80=9Dsv`.</div><div><br></div><div>--</div><div>Pavel<br><div><br>26 =
=D0=BE=D0=BA=D1=82. 2017 =D0=B3., =D0=B2 0:02, Nevin Liber <<a href=3D"m=
ailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>> =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):<br><br></div><blockquote type=3D"ci=
te"><div><div dir=3D"ltr">On Wed, Oct 25, 2017 at 3:07 PM, <span dir=3D"lt=
r"><<a href=3D"mailto:pavel.kryukov@phystech.edu" target=3D"_blank">pave=
l.kryukov@phystech.edu</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
Hi<div><br></div><div>If there was a ctor from array reference, would it be=
noexcept?</div><div><br></div><div>template<size_t N></div><div>cons=
texpr basic_string_view(const charT(&str)[N]) noexcept;</div></div></bl=
ockquote><div><br></div><div>It hasn't been proposed, has it?</div><div><br=
></div><div>My guess would be no, since there is a precondition that str[N-=
1] =3D=3D 0, giving it a narrow contract.</div></div>-- <br><div class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><d=
iv dir=3D"ltr"><div> Nevin ":-)" Liber <mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
; +1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FaBXmXBWHHI/unsubscribe">https://groups.=
google.com/a/isocpp.org/d/topic/std-proposals/FaBXmXBWHHI/unsubscribe</a>.<=
br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+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/CAGg_6%2BPv2BYcxMJ5aQ9uLb2qpgVZ3ThFjo=
WdKBNyZ4oNPm0A-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPv=
2BYcxMJ5aQ9uLb2qpgVZ3ThFjoWdKBNyZ4oNPm0A-A%40mail.gmail.com</a>.<br>
</div></blockquote></div></body></html>
<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/89333EED-6CC2-43D5-9EFB-C2F59E5819A2%=
40phystech.edu?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/89333EED-6CC2-43D5-9EFB-C2F59E5819=
A2%40phystech.edu</a>.<br />
--Apple-Mail-A0855A3F-CC91-49F6-8BFC-54DCF32ADA1A--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 25 Oct 2017 16:09:33 -0700
Raw View
On Wednesday, 25 October 2017 14:02:33 PDT Nevin Liber wrote:
> On Wed, Oct 25, 2017 at 3:07 PM, <pavel.kryukov@phystech.edu> wrote:
> > Hi
> >
> > If there was a ctor from array reference, would it be noexcept?
> >
> > template<size_t N>
> > constexpr basic_string_view(const charT(&str)[N]) noexcept;
>
> It hasn't been proposed, has it?
>
> My guess would be no, since there is a precondition that str[N-1] == 0,
> giving it a narrow contract.
Why would it have such a precondition?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/5949784.ta64GYsRuq%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 25 Oct 2017 19:17:01 -0500
Raw View
--001a114159eec1cb92055c68194b
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 25, 2017 at 6:09 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> > > template<size_t N>
> > > constexpr basic_string_view(const charT(&str)[N]) noexcept;
> >
> > It hasn't been proposed, has it?
> >
> > My guess would be no, since there is a precondition that str[N-1] == 0,
> > giving it a narrow contract.
>
> Why would it have such a precondition?
>
This constructor is unnecessary unless you want to differentiate between
C-string literals and raw pointers (which is a breaking change BTW).
The problem is, C-string literals are not represented in the type system.
The closest, and by no means is it perfect, is a const char(&str)[N] where
!str[N-1] holds.
Take the following:
string_view a("Hello");
const char s[] = { 'H', 'e', 'l', 'l', 'o' };
string_view b(s);
string_view c("Hello\0World");
Right now:
a.size() == 5;
b.size() // UB
c.size() == 5;
With this change, what should a.size(), b.size() and c.size() be?
Boost.Range has as_literal because you cannot in general deduce the intent
from the type alone.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BO6VhTD2vJoLVDONbbfw5EdSU5CW4D_KCdEvPT2V0DGrA%40mail.gmail.com.
--001a114159eec1cb92055c68194b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 25, 2017 at 6:09 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> >=
; template<size_t N><br>
> > constexpr basic_string_view(const charT(&str)[N]) noexcept;<b=
r>
><br>
> It hasn't been proposed, has it?<br>
><br>
> My guess would be no, since there is a precondition that str[N-1] =3D=
=3D 0,<br>
> giving it a narrow contract.<br>
<br>
</span>Why would it have such a precondition?<br></blockquote><div><br></di=
v><div>This constructor is unnecessary unless you want to differentiate bet=
ween C-string literals and raw pointers (which is a breaking change BTW).</=
div><div><br></div><div>The problem is, C-string literals are not represent=
ed in the type system.</div><div><br></div><div>The closest, and by no mean=
s is it perfect, is a const char(&str)[N] where !str[N-1] holds.</div><=
div><br></div><div>Take the following:</div><div><br></div><div>string_view=
a("Hello");</div><div>const char s[] =3D { 'H', 'e&#=
39;, 'l', 'l', 'o' };</div><div>string_view b(s);</=
div><div>string_view c("Hello\0World");</div><div><br></div><div>=
Right now:</div><div><br></div><div>a.size() =3D=3D 5;</div><div>b.size() /=
/ UB</div><div>c.size() =3D=3D 5;</div><div><br></div><div>With this change=
, what should a.size(), b.size() and c.size() be?</div><div><br></div><div>=
Boost.Range has as_literal because you cannot in general deduce the intent =
from the type alone.</div></div>-- <br><div class=3D"gmail_signature" data-=
smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1=
-847-691-1404</div></div></div></div></div>
</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/CAGg_6%2BO6VhTD2vJoLVDONbbfw5EdSU5CW4=
D_KCdEvPT2V0DGrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO6VhTD=
2vJoLVDONbbfw5EdSU5CW4D_KCdEvPT2V0DGrA%40mail.gmail.com</a>.<br />
--001a114159eec1cb92055c68194b--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 25 Oct 2017 20:51:43 -0500
Raw View
--001a114b6d0665b9ab055c696cf1
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 25, 2017 at 7:17 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> This constructor is unnecessary unless you want to differentiate between
> C-string literals and raw pointers (which is a breaking change BTW).
>
Technically, it doesn't have to be a breaking change, as long as all it
does is define behavior for:
> const char s[] = { 'H', 'e', 'l', 'l', 'o' };
> string_view b(s);
>
> Right now:
>
> b.size() // UB
>
I don't see that as particularly useful.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BO%3DN_3nogd-RbCGbAXAyX00UxETAgH6hZ5eJZoEyV001w%40mail.gmail.com.
--001a114b6d0665b9ab055c696cf1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 25, 2017 at 7:17 PM, Nevin Liber <span dir=3D"=
ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>This constructor is unnecessary unle=
ss you want to differentiate between C-string literals and raw pointers (wh=
ich is a breaking change BTW).</div></div></div></div></blockquote><div><br=
></div><div>Technically, it doesn't have to be a breaking change, as lo=
ng as all it does is define behavior for:</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div>const char s[] =3D { 'H', 'e', 'l', 'l&#=
39;, 'o' };</div><div>string_view b(s);</div><div><br></div><div>Ri=
ght now:</div><div><br></div><div>b.size() // UB</div></div></div></div></b=
lockquote><div><br></div><div>I don't see that as particularly useful.<=
/div><div>--=C2=A0<br></div></div><div class=3D"gmail_signature"><div dir=
=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0=
<mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nev=
in@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></=
div>
</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/CAGg_6%2BO%3DN_3nogd-RbCGbAXAyX00UxET=
AgH6hZ5eJZoEyV001w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO%3D=
N_3nogd-RbCGbAXAyX00UxETAgH6hZ5eJZoEyV001w%40mail.gmail.com</a>.<br />
--001a114b6d0665b9ab055c696cf1--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 25 Oct 2017 19:16:55 -0700
Raw View
On Wednesday, 25 October 2017 18:51:43 PDT Nevin Liber wrote:
> Technically, it doesn't have to be a breaking change, as long as all it
>
> does is define behavior for:
> > const char s[] = { 'H', 'e', 'l', 'l', 'o' };
> > string_view b(s);
> >
> > Right now:
> >
> > b.size() // UB
>
> I don't see that as particularly useful.
QStringView has both a pointer and an array constructor. That means:
const char16_t str[] = u"Hello\0World";
QStringView(str).size() == 11 // constexpr
QStringView(+str).size() == 5 // not constexpr
We've also had a long-time issue with embedded nuls in arrays in other
contexts. For example:
const char data[] = "Hello World";
QByteArray ba(data);
ba[5] = '\0';
return QString::fromLatin1(ba);
Previously, QString::fromLatin1 did not have an overload for QByteArray, so it
was automatically cast to const char* and strlen applied. So this code
returned "Hello".
At some point, we added the overload, but it broke a lot of code that depended
on the null stopping the conversion. And it wasn't just a handful of cases,
plus they were quite difficult to track down.
If we had added the constructor at the moment the class was introduced, there
would have been no legacy to deal with. Now there will be, so it needs to be
done with great care.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/5005582.pCRZNEiGFO%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 25 Oct 2017 21:30:21 -0500
Raw View
--001a114b6d0699a48d055c69f69a
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 25, 2017 at 9:16 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Wednesday, 25 October 2017 18:51:43 PDT Nevin Liber wrote:
> > Technically, it doesn't have to be a breaking change, as long as all it
> >
> > does is define behavior for:
> > > const char s[] = { 'H', 'e', 'l', 'l', 'o' };
> > > string_view b(s);
> > >
> > > Right now:
> > >
> > > b.size() // UB
> >
> > I don't see that as particularly useful.
>
> QStringView has both a pointer and an array constructor. That means:
>
> const char16_t str[] = u"Hello\0World";
>
> QStringView(str).size() == 11 // constexpr
> QStringView(+str).size() == 5 // not constexpr
>
I'm not sure what constexpr has to do with it. Isn't it array vs. pointer
that matters?
It also means
QStringView(b ? u"Hello\0World" : u"Howdy\0World") has subtly different
behavior than QStringView(b ? u"Hello\0World" : u"Goodbye\0World"), doesn't
it?
> If we had added the constructor at the moment the class was introduced,
> there
> would have been no legacy to deal with. Now there will be, so it needs to
> be
> done with great care.
>
Again, I think matching an array is the wrong solution to the question of
"is this a string literal"?
A better solution might be a magic type that, in template contexts, matches
better than an array but easily decays to an array. OTOH, it might not be
(I haven't really thought about it much). And it still wouldn't address
the ternary operator problem I mentioned above.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--
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/CAGg_6%2BM1gvNh82YX6x4Nr3%3DrFSPW973nmumTF0SkyMJ7c2Yoew%40mail.gmail.com.
--001a114b6d0699a48d055c69f69a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 25, 2017 at 9:16 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wednesday, 25 Oc=
tober 2017 18:51:43 PDT Nevin Liber wrote:<br>
> Technically, it doesn't have to be a breaking change, as long as a=
ll it<br>
><br>
> does is define behavior for:<br>
> > const char s[] =3D { 'H', 'e', 'l', '=
l', 'o' };<br>
> > string_view b(s);<br>
> ><br>
> > Right now:<br>
> ><br>
> > b.size() // UB<br>
><br>
> I don't see that as particularly useful.<br>
<br>
</span>QStringView has both a pointer and an array constructor. That means:=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 const char16_t str[] =3D u"Hello\0World&qu=
ot;;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QStringView(str).size() =3D=3D 11=C2=A0 =C2=A0/=
/ constexpr<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QStringView(+str).size() =3D=3D 5=C2=A0 =C2=A0/=
/ not constexpr<br></blockquote><div><br></div><div>I'm not sure what c=
onstexpr has to do with it.=C2=A0 Isn't it array vs. pointer that matte=
rs?</div><div><br></div><div>It also means</div><div><br></div><div>QString=
View(b ? u"Hello\0World" : u"Howdy\0World") has subtly =
different behavior than QStringView(b ? u"Hello\0World" : u"=
Goodbye\0World"), doesn't it?</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
If we had added the constructor at the moment the class was introduced, the=
re<br>
would have been no legacy to deal with. Now there will be, so it needs to b=
e<br>
done with great care.<br></blockquote><div><br></div><div>Again, I think ma=
tching an array is the wrong solution to the question of "is this a st=
ring literal"?</div><div><br></div><div>A better solution might be a m=
agic type that, in template contexts, matches better than an array but easi=
ly decays to an array.=C2=A0 OTOH, it might not be (I haven't really th=
ought about it much).=C2=A0 And it still wouldn't address the ternary o=
perator problem I mentioned above.</div></div>-- <br><div class=3D"m_-19439=
6159271978786m_-3005333622292479268gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":=
-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a><wbr>> =C2=A0<a href=3D"tel:(=
847)%20691-1404" value=3D"+18476911404" target=3D"_blank">+1-847-691-1404</=
a></div></div></div></div></div>
</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/CAGg_6%2BM1gvNh82YX6x4Nr3%3DrFSPW973n=
mumTF0SkyMJ7c2Yoew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM1gv=
Nh82YX6x4Nr3%3DrFSPW973nmumTF0SkyMJ7c2Yoew%40mail.gmail.com</a>.<br />
--001a114b6d0699a48d055c69f69a--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 25 Oct 2017 20:04:40 -0700
Raw View
On Wednesday, 25 October 2017 19:30:21 PDT Nevin Liber wrote:
> > QStringView has both a pointer and an array constructor. That means:
> > const char16_t str[] = u"Hello\0World";
> >
> > QStringView(str).size() == 11 // constexpr
> > QStringView(+str).size() == 5 // not constexpr
>
> I'm not sure what constexpr has to do with it. Isn't it array vs. pointer
> that matters?
Just a dig at the inability to overload on constexprness.
Calculating the length of char16_t(&)[N] is easy: N - 1.
Calculating the length of char16_t* can't be done in a constexpr way.
> It also means
>
> QStringView(b ? u"Hello\0World" : u"Howdy\0World") has subtly different
> behavior than QStringView(b ? u"Hello\0World" : u"Goodbye\0World"), doesn't
> it?
Uh... I don't know. godbolting to the rescue...
Why does this call the pointer version?
template <unsigned N> void f(const char (&)[N]);
void f(const char *);
void g(bool b)
{
const char str[] = "World";
f(str);
}
> > If we had added the constructor at the moment the class was introduced,
> > there
> > would have been no legacy to deal with. Now there will be, so it needs to
> > be
> > done with great care.
>
> Again, I think matching an array is the wrong solution to the question of
> "is this a string literal"?
Indeed.
> A better solution might be a magic type that, in template contexts, matches
> better than an array but easily decays to an array. OTOH, it might not be
> (I haven't really thought about it much). And it still wouldn't address
> the ternary operator problem I mentioned above.
libstdc++ has a GCC-specific solution for string_view: __builtin_constant_p.
Using that, they can determine whether it is a string literal and they can
even do a constexpr strlen() for those. They do stop at a null, but that's by
design.
See the tricks here:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
char_traits.h#L220-L252
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/3446274.dRsjijLxpX%40tjmaciei-mobl1.
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Thu, 26 Oct 2017 10:40:50 +0200
Raw View
On 2017-10-25 22:07, pavel.kryukov@phystech.edu wrote:
> Hi
>
> If there was a ctor from array reference, would it be noexcept?
>
> template<size_t N>
> constexpr basic_string_view(const charT(&str)[N]) noexcept;
This one still has the precondition that [Char, N) is a valid range. It
might not be:
char bug[512];
auto s = string_view(bug);
but you can't check (in C++) for that.
FWIW, QStringView's Char[N] and Char* ctors are noexcept while the
(Char*, n) and (Char*, Char*) ones are not. I believe I did it like that
according to (non-/)checkability of preconditions (you can't check for
precondition violations for the first two, but you can check for some
violations for the other two). If you can't check using C++, then you
can't add an assert[1].
> Of course, you may do reinterpret_cast and pass something wrong to it,
> but it would be programmer's responsibility.
Meeting the preconditions of a function he's calling is _always_ the
programmer's responsibility.
Thanks,
Marc
[1] not entirely true: https://codereview.qt-project.org/193707
--
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/172fc6328e80a64a748e4fabe78cfa5f%40kdab.com.
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Thu, 26 Oct 2017 10:55:04 +0200
Raw View
On 2017-10-26 05:04, Thiago Macieira wrote:
> On Wednesday, 25 October 2017 19:30:21 PDT Nevin Liber wrote:
>> > QStringView has both a pointer and an array constructor. That means:
>> > const char16_t str[] = u"Hello\0World";
>> >
>> > QStringView(str).size() == 11 // constexpr
>> > QStringView(+str).size() == 5 // not constexpr
>>
>> I'm not sure what constexpr has to do with it. Isn't it array vs.
>> pointer
>> that matters?
>
> Just a dig at the inability to overload on constexprness.
In QStringView, it's just an optimisation, because...
> Calculating the length of char16_t(&)[N] is easy: N - 1.
.... this is C++11-constexpr (which we still need to care for, in Qt)
while ...
> Calculating the length of char16_t* can't be done in a constexpr way.
.... is only C++14-constexpr (well, if you want to support reasonably
long strings, otherwise you could come up with a recursive
implementation).
We should probably document that the QStringView array ctor has the
precondition that it contains no embedded NULs, but it seems qdoc is too
clever for it's own good:
https://doc-snapshots.qt.io/qt5-5.10/qstringview.html doesn't have the
docs for the array ctor.
>> It also means
>>
>> QStringView(b ? u"Hello\0World" : u"Howdy\0World") has subtly
>> different
>> behavior than QStringView(b ? u"Hello\0World" : u"Goodbye\0World"),
>> doesn't
>> it?
>
> Uh... I don't know. godbolting to the rescue...
>
> Why does this call the pointer version?
> template <unsigned N> void f(const char (&)[N]);
> void f(const char *);
>
> void g(bool b)
> {
> const char str[] = "World";
> f(str);
> }
Because ordinary functions are preferred over templates. You need
constrained templates to overload on pointer vs. array:
https://www.kdab.com/qstringview-diaries-masters-overloads/ (can't seem
to link to a section, C-F for 'third').
Thanks,
Marc
--
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/a82f7b048d91673203c75fa04e98f481%40kdab.com.
.
Author: pavel.kryukov@phystech.edu
Date: Thu, 26 Oct 2017 02:30:45 -0700 (PDT)
Raw View
------=_Part_235_2019475208.1509010245388
Content-Type: multipart/alternative;
boundary="----=_Part_236_1993802447.1509010245388"
------=_Part_236_1993802447.1509010245388
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> This one still has the precondition that [Char, N) is a valid range. It=
=20
> might not be:=20
> char bug[512];=20
> auto s =3D string_view(bug);=20
Should std::string_view have such precondition, isn't it just a wrapper=20
around pointer and size which may dangle?
You may construct a nullptr string_view using argument-less ctor (it is=20
even noexcept) or get a valid string_view from a valid string, but then=20
break it.
auto tmp =3D new std::string("Hello World");
std::string_view sv(tmp.c_str());
delete tmp;
Thanks,
--
Pavel
=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 26 =D0=BE=D0=BA=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2017 =D0=B3., 11:55:14 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Marc Mutz =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
>
> On 2017-10-26 05:04, Thiago Macieira wrote:=20
> > On Wednesday, 25 October 2017 19:30:21 PDT Nevin Liber wrote:=20
> >> > QStringView has both a pointer and an array constructor. That means:=
=20
> >> > const char16_t str[] =3D u"Hello\0World";=20
> >> >=20
> >> > QStringView(str).size() =3D=3D 11 // constexpr=20
> >> > QStringView(+str).size() =3D=3D 5 // not constexpr=20
> >>=20
> >> I'm not sure what constexpr has to do with it. Isn't it array vs.=20
> >> pointer=20
> >> that matters?=20
> >=20
> > Just a dig at the inability to overload on constexprness.=20
>
> In QStringView, it's just an optimisation, because...=20
>
> > Calculating the length of char16_t(&)[N] is easy: N - 1.=20
>
> ... this is C++11-constexpr (which we still need to care for, in Qt)=20
> while ...=20
>
> > Calculating the length of char16_t* can't be done in a constexpr way.=
=20
>
> ... is only C++14-constexpr (well, if you want to support reasonably=20
> long strings, otherwise you could come up with a recursive=20
> implementation).=20
>
> We should probably document that the QStringView array ctor has the=20
> precondition that it contains no embedded NULs, but it seems qdoc is too=
=20
> clever for it's own good:=20
> https://doc-snapshots.qt.io/qt5-5.10/qstringview.html doesn't have the=20
> docs for the array ctor.=20
>
> >> It also means=20
> >>=20
> >> QStringView(b ? u"Hello\0World" : u"Howdy\0World") has subtly=20
> >> different=20
> >> behavior than QStringView(b ? u"Hello\0World" : u"Goodbye\0World"),=20
> >> doesn't=20
> >> it?=20
> >=20
> > Uh... I don't know. godbolting to the rescue...=20
> >=20
> > Why does this call the pointer version?=20
> > template <unsigned N> void f(const char (&)[N]);=20
> > void f(const char *);=20
> >=20
> > void g(bool b)=20
> > {=20
> > const char str[] =3D "World";=20
> > f(str);=20
> > }=20
>
> Because ordinary functions are preferred over templates. You need=20
> constrained templates to overload on pointer vs. array:=20
> https://www.kdab.com/qstringview-diaries-masters-overloads/ (can't seem=
=20
> to link to a section, C-F for 'third').=20
>
> Thanks,=20
> Marc=20
>
>
--=20
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 e=
mail 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/545c118e-8d6d-456b-a640-0e3c0784f583%40isocpp.or=
g.
------=_Part_236_1993802447.1509010245388
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> This one still has the precondition that [Char, N) is=
a valid range. It=C2=A0<br>> might not be:=C2=A0<div><br>>=C2=A0 =C2=
=A0 char bug[512];=C2=A0<br>>=C2=A0 =C2=A0 auto s =3D string_view(bug);=
=C2=A0<div><br></div><div>Should std::string_view have such precondition, i=
sn't it just a wrapper around pointer and size which may dangle?</div><=
div>You may construct a nullptr string_view using argument-less ctor (it is=
even noexcept) or get a valid string_view from a valid string, but then br=
eak it.</div><div><br></div><div>auto tmp =3D new std::string("Hello W=
orld");</div><div>std::string_view sv(tmp.c_str());</div><div>delete t=
mp;</div><div><br></div><div>Thanks,</div><div>--</div><div>Pavel</div><div=
><br>=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 26 =D0=BE=D0=BA=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2017 =D0=B3., 11:55:14 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Marc Mutz =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
2017-10-26 05:04, Thiago Macieira wrote:
<br>> On Wednesday, 25 October 2017 19:30:21 PDT Nevin Liber wrote:
<br>>> > QStringView has both a pointer and an array constructor. =
That means:
<br>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 const char16_t str[] =3D u&qu=
ot;Hello\0World";
<br>>> >
<br>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QStringView(str).size() =3D=
=3D 11 =C2=A0 // constexpr
<br>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QStringView(+str).size() =3D=
=3D 5 =C2=A0 // not constexpr
<br>>>=20
<br>>> I'm not sure what constexpr has to do with it. =C2=A0Isn&#=
39;t it array vs.=20
<br>>> pointer
<br>>> that matters?
<br>>=20
<br>> Just a dig at the inability to overload on constexprness.
<br>
<br>In QStringView, it's just an optimisation, because...
<br>
<br>> Calculating the length of char16_t(&)[N] is easy: N - 1.
<br>
<br>... this is C++11-constexpr (which we still need to care for, in Qt)=20
<br>while ...
<br>
<br>> Calculating the length of char16_t* can't be done in a constex=
pr way.
<br>
<br>... is only C++14-constexpr (well, if you want to support reasonably=20
<br>long strings, otherwise you could come up with a recursive=20
<br>implementation).
<br>
<br>We should probably document that the QStringView array ctor has the=20
<br>precondition that it contains no embedded NULs, but it seems qdoc is to=
o=20
<br>clever for it's own good:=20
<br><a href=3D"https://doc-snapshots.qt.io/qt5-5.10/qstringview.html" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.g=
oogle.com/url?q\x3dhttps%3A%2F%2Fdoc-snapshots.qt.io%2Fqt5-5.10%2Fqstringvi=
ew.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGC3_9RFNqXxNXbggV2rzKniOmWM=
A';return true;" onclick=3D"this.href=3D'https://www.google.com/url=
?q\x3dhttps%3A%2F%2Fdoc-snapshots.qt.io%2Fqt5-5.10%2Fqstringview.html\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGC3_9RFNqXxNXbggV2rzKniOmWMA';return=
true;">https://doc-snapshots.qt.io/<wbr>qt5-5.10/qstringview.html</a> does=
n't have the=20
<br>docs for the array ctor.
<br>
<br>>> It also means
<br>>>=20
<br>>> QStringView(b ? u"Hello\0World" : u"Howdy\0Worl=
d") has subtly=20
<br>>> different
<br>>> behavior than QStringView(b ? u"Hello\0World" : u&qu=
ot;Goodbye\0World"),=20
<br>>> doesn't
<br>>> it?
<br>>=20
<br>> Uh... I don't know. godbolting to the rescue...
<br>>=20
<br>> Why does this call the pointer version?
<br>> template <unsigned N> void f(const char (&)[N]);
<br>> void f(const char *);
<br>>=20
<br>> void g(bool b)
<br>> {
<br>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0const char str[] =
=3D "World";
<br>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f(str);
<br>> }
<br>
<br>Because ordinary functions are preferred over templates. You need=20
<br>constrained templates to overload on pointer vs. array:=20
<br><a href=3D"https://www.kdab.com/qstringview-diaries-masters-overloads/"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fwww.kdab.com%2Fqstringview-diaries-m=
asters-overloads%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFwd-R_i6_H0P57D=
f26OsN74RqcLg';return true;" onclick=3D"this.href=3D'https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fwww.kdab.com%2Fqstringview-diaries-masters-=
overloads%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFwd-R_i6_H0P57Df26OsN7=
4RqcLg';return true;">https://www.kdab.com/<wbr>qstringview-diaries-mas=
ters-<wbr>overloads/</a> (can't seem=20
<br>to link to a section, C-F for 'third').
<br>
<br>Thanks,
<br>Marc
<br>
<br></blockquote></div></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/545c118e-8d6d-456b-a640-0e3c0784f583%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/545c118e-8d6d-456b-a640-0e3c0784f583=
%40isocpp.org</a>.<br />
------=_Part_236_1993802447.1509010245388--
------=_Part_235_2019475208.1509010245388--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Thu, 26 Oct 2017 11:55:08 +0200
Raw View
On 2017-10-26 11:30, pavel.kryukov@phystech.edu wrote:
>> This one still has the precondition that [Char, N) is a valid range.
> It
>> might not be:
>
>> char bug[512];
>> auto s = string_view(bug);
>
> Should std::string_view have such precondition, isn't it just a
> wrapper around pointer and size which may dangle?
Yes, it should, IMHO. Consider;
f(std::string); // wide contract: all strings are acceptable
f(const char *s, size_t n); // narrow contract: [s,n) must be valid
range
f(std::string_view); // wide or narrow contract?
By putting the precondition on the string_view ctor, we gain wide
contracts for any string_view function. This means they can be noexcept,
and that is much more valuable than having a noexcept string_view ctor
(which is inline), because string_view-taking functions are often
out-of-line, so marking them noexcept (where no additional preconditions
prevent it) actually helps the compiler.
> You may construct a nullptr string_view using argument-less ctor (it
> is even noexcept)
Yes, and?
> or get a valid string_view from a valid string, but
> then break it.
>
> auto tmp = new std::string("Hello World");
> std::string_view sv(tmp.c_str());
> delete tmp;
Yes, this is a problem. But I'm not sure that it actually can be
formulated with the term 'precondition'. The closest I can come up with
is an external class invariant, which is a bit of an oxymoron to start
with, because classes exist to establish and maintain their invariants.
But it's not really different from std::ref, say.
Thanks,
Marc
--
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/e989bea8667eb2c1c36f370e259e00c2%40kdab.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 26 Oct 2017 09:09:32 -0700
Raw View
On Thursday, 26 October 2017 01:55:04 PDT Marc Mutz wrote:
> > Calculating the length of char16_t* can't be done in a constexpr way.
>
> ... is only C++14-constexpr (well, if you want to support reasonably
> long strings, otherwise you could come up with a recursive
> implementation).
No, it's not constexpr at all, since I can't run SSE or do reinterpret_cast
from pointer to integer and back in constexpr mode.
See http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/
qstring.cpp#n163
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/1931282.giciDSTxGt%40tjmaciei-mobl1.
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Thu, 26 Oct 2017 19:44:04 +0200
Raw View
On 2017-10-26 18:09, Thiago Macieira wrote:
> On Thursday, 26 October 2017 01:55:04 PDT Marc Mutz wrote:
>> > Calculating the length of char16_t* can't be done in a constexpr way.
>>
>> ... is only C++14-constexpr (well, if you want to support reasonably
>> long strings, otherwise you could come up with a recursive
>> implementation).
>
> No, it's not constexpr at all, since I can't run SSE or do
> reinterpret_cast
> from pointer to integer and back in constexpr mode.
>
> See http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/
> qstring.cpp#n163
You'd think compilers would recognize an inlined strlen call and throw
their own vectoriser at it, no? If not strlen, what else could they
possibly auto-vectorise at all? :)
And, yes, you can call such functions in constexpr functions: Just loop
inline for, say, 64bytes and, if you haven't found the end by then, call
the out-of-line hand-optimized function to do the rest.
Thanks,
Marc
--
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/1f284e0dd9faeabf60b45140e4c1a2b3%40kdab.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 26 Oct 2017 13:37:59 -0700
Raw View
On Thursday, 26 October 2017 10:44:04 PDT Marc Mutz wrote:
> On 2017-10-26 18:09, Thiago Macieira wrote:
> > No, it's not constexpr at all, since I can't run SSE or do
> > reinterpret_cast
> > from pointer to integer and back in constexpr mode.
> >
> > See http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/
> > qstring.cpp#n163
>
> You'd think compilers would recognize an inlined strlen call and throw
> their own vectoriser at it, no? If not strlen, what else could they
> possibly auto-vectorise at all? :)
I would. That's what GCC does:
https://code.woboq.org/gcc/libstdc++-v3/include/bits/char_traits.h.html#267
But note how that's only specialised for char_traits<char> and
char_traits<wchar_t>.
Also note how the constexpr keyword is commented out in this listing.
Unfortunately, Woboq has an older version of GCC; version 7 introduced that
__builtin_constant_p trick that I mentioned for char and wchar_t.
> And, yes, you can call such functions in constexpr functions: Just loop
> inline for, say, 64bytes and, if you haven't found the end by then, call
> the out-of-line hand-optimized function to do the rest.
That's doubly bad in my opinion:
1) it looks constexpr, but isn't for some data, leading to surprises. You
can't rely on it to create a constexpr QStringView.
2) it inserts that loop into user code that does 1 to 32 2-byte loads, instead
of the much faster 1 to 5 16-byte memory loads.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2344937.8oWqZGD8jr%40tjmaciei-mobl1.
.