Topic: std::unreachable: the message parameter
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 22 Nov 2017 11:06:23 -0800 (PST)
Raw View
------=_Part_11274_455724614.1511377583455
Content-Type: multipart/alternative;
boundary="----=_Part_11275_1740156890.1511377583455"
------=_Part_11275_1740156890.1511377583455
Content-Type: text/plain; charset="UTF-8"
The consensus of the Toronto meeting's EWG was that std::unreachable,
intentionally causing undefined behavior, should have two forms:
[[noreturn]] void unreachable();
[[noreturn]] void unreachable($literal string$);
The intent is similar to that of static_assert: have a diagnostic message
that could be shown when an unreachable statement is executed in a debug
build.
What I'm wondering is how unreachable should take that parameter. The
obvious would be the following:
[[noreturn]] void unreachable(const char *message);
This would allow literal strings, but it would also allow constructions
like the following:
void f(int i) {
switch (i) {
case 0:
case 2:
something();
break;
default: {
char message[64];
std::snprintf(message, sizeof(message), "unknown value: %d", i);
std::unreachable(message);
}
}
}
Should such constructions be allowed, or should a literal string be
required? If a literal string, how would that even be enforced, given that
this is a library function?
In optimized builds in a mode in which the compiler does not output a
diagnostic message, the call to std::snprintf could be elided by a smart
compiler; if the compiler knows that the only observable effect of
std::snprintf is to modify "message", it could elide the call because
std::unreachable is presumably implemented as an inline function.
I was considering wording such as the following, under the assumption that
a runtime value of "message" is allowed:
"If an implementation issues a diagnostic upon the execution of
std::unreachable(), and the 'message' parameter is present, the diagnostic
message should include the characters of 'message' that are in the
execution character set."
Melissa
--
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/590f2abd-b676-4241-ae0d-1c7c95b8fe7d%40isocpp.org.
------=_Part_11275_1740156890.1511377583455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The consensus of the Toronto meeting's EWG was that st=
d::unreachable, intentionally causing undefined behavior, should have two f=
orms:<br><br>[[noreturn]] void unreachable();<br>[[noreturn]] void unreacha=
ble($literal string$);<br><br>The intent is similar to that of static_asser=
t: have a diagnostic message that could be shown when an unreachable statem=
ent is executed in a debug build.<br><br>What I'm wondering is how unre=
achable should take that parameter.=C2=A0 The obvious would be the followin=
g:<br><br>[[noreturn]] void unreachable(const char *message);<br><br>This w=
ould allow literal strings, but it would also allow constructions like the =
following:<br><br>void f(int i) {<br>=C2=A0=C2=A0=C2=A0 switch (i) {<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 case 2:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 something();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 default: {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 char message[64];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::snprintf(message, sizeof(message), &quo=
t;unknown value: %d", i);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unreachable(message);<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>Should su=
ch constructions be allowed, or should a literal string be required?=C2=A0 =
If a literal string, how would that even be enforced, given that this is a =
library function?<br><br>In optimized builds in a mode in which the compile=
r does not output a diagnostic message, the call to std::snprintf could be =
elided by a smart compiler; if the compiler knows that the only observable =
effect of std::snprintf is to modify "message", it could elide th=
e call because std::unreachable is presumably implemented as an inline func=
tion.<br><br>I was considering wording such as the following, under the ass=
umption that a runtime value of "message" is allowed:<br><br>&quo=
t;If an implementation issues a diagnostic upon the execution of std::unrea=
chable(), and the 'message' parameter is present, the diagnostic me=
ssage should include the characters of 'message' that are in the ex=
ecution character set."<br><br>Melissa<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/590f2abd-b676-4241-ae0d-1c7c95b8fe7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/590f2abd-b676-4241-ae0d-1c7c95b8fe7d=
%40isocpp.org</a>.<br />
------=_Part_11275_1740156890.1511377583455--
------=_Part_11274_455724614.1511377583455--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 22 Nov 2017 20:10:05 -0800 (PST)
Raw View
------=_Part_12319_1771334960.1511410205887
Content-Type: multipart/alternative;
boundary="----=_Part_12320_1597834854.1511410205888"
------=_Part_12320_1597834854.1511410205888
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 22, 2017 at 11:06:23 AM UTC-8, Myriachan wrote:
>
> The consensus of the Toronto meeting's EWG was that std::unreachable,=20
> intentionally causing undefined behavior, should have two forms:
>
> [[noreturn]] void unreachable();
> [[noreturn]] void unreachable($literal string$);
>
> The intent is similar to that of static_assert: have a diagnostic message=
=20
> that could be shown when an unreachable statement is executed in a debug=
=20
> build.
>
> What I'm wondering is how unreachable should take that parameter. The=20
> obvious would be the following:
>
> [[noreturn]] void unreachable(const char *message);
>
Yes, that's correct.
=20
> This would allow literal strings, but it would also allow constructions=
=20
> like the following:
>
> void f(int i) {
> switch (i) {
> case 0:
> case 2:
> something();
> break;
> default: {
> char message[64];
> std::snprintf(message, sizeof(message), "unknown value: %d",=
=20
> i);
> std::unreachable(message);
> }
> }
> }
>
> Should such constructions be allowed, or should a literal string be=20
> required? If a literal string, how would that even be enforced, given th=
at=20
> this is a library function?
>
I see no reason to require a literal string. The implementation of=20
std::unreachable(const char*) would look like this on GCC and Clang:
[[noreturn]] void unreachable(const char *msg) {
#ifdef DEBUG_MODE
fprintf(stderr, "%s\n", msg);
abort();
#else
__builtin_unreachable();
#endif
}
Nothing here requires a literal string.
In optimized builds in a mode in which the compiler does not output a=20
> diagnostic message, the call to std::snprintf could be elided by a smart=
=20
> compiler; if the compiler knows that the only observable effect of=20
> std::snprintf is to modify "message", it could elide the call because=20
> std::unreachable is presumably implemented as an inline function.
>
Correct. In optimized builds, std::unreachable() had darn well BETTER be=20
equivalent to __builtin_unreachable().
In debug builds, a vendor might (unlikely IMO but possible) choose to print=
=20
the given message and then abort. In that case, the call to std::snprintf=
=20
could not be elided by the compiler, because its output was actually being=
=20
used.
I was considering wording such as the following, under the assumption that=
=20
> a runtime value of "message" is allowed:
>
> "If an implementation issues a diagnostic upon the execution of=20
> std::unreachable(), and the 'message' parameter is present, the diagnosti=
c=20
> message should include the characters of 'message' that are in the=20
> execution character set."
>
Assuming (correctly IMO) that the 'message' parameter is a `const char*`,=
=20
it points to a null-terminated sequence of characters, which by definition=
=20
are in the execution character set. The translation of a string literal (if=
=20
any) from the source character set into a sequence of bytes in the=20
execution character set has, by runtime, already happened; and therefore=20
std::unreachable() doesn't need to do anything special to deal with it.
=E2=80=93Arthur
--=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/5a8666ef-278e-4636-baaa-8f71c5a54a2d%40isocpp.or=
g.
------=_Part_12320_1597834854.1511410205888
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 22, 2017 at 11:06:23 AM UTC-8, Myri=
achan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
he consensus of the Toronto meeting's EWG was that std::unreachable, in=
tentionally causing undefined behavior, should have two forms:<br><br>[[nor=
eturn]] void unreachable();<br>[[noreturn]] void unreachable($literal strin=
g$);<br><br>The intent is similar to that of static_assert: have a diagnost=
ic message that could be shown when an unreachable statement is executed in=
a debug build.<br><br>What I'm wondering is how unreachable should tak=
e that parameter.=C2=A0 The obvious would be the following:<br><br>[[noretu=
rn]] void unreachable(const char *message);<br></div></blockquote><div><br>=
</div><div>Yes, that's correct.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">This would allow literal strin=
gs, but it would also allow constructions like the following:<br><br>void f=
(int i) {<br>=C2=A0=C2=A0=C2=A0 switch (i) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 case 0:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case =
2:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so=
mething();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 break;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default: {<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char mes=
sage[64];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 std::snprintf(message, sizeof(message), "unknown value: %d"=
;, i);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 std::unreachable(message);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>Should such constructions be allo=
wed, or should a literal string be required?=C2=A0 If a literal string, how=
would that even be enforced, given that this is a library function?<br></d=
iv></blockquote><div><br></div><div>I see no reason to require a literal st=
ring. The implementation of std::unreachable(const char*) would look like t=
his on GCC and Clang:</div><div><br></div><div>[[noreturn]] void unreachabl=
e(const char *msg) {</div><div>=C2=A0 =C2=A0 #ifdef DEBUG_MODE</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fprintf(stderr, "%s\n", msg);</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 abort();</div><div>=C2=A0 =C2=A0 #else</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __builtin_unreachable();</div><div>=C2=A0 =
=C2=A0 #endif</div><div>}</div><div><br></div><div>Nothing here requires a =
literal string.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">In optimized builds in a mode in which the compiler =
does not output a diagnostic message, the call to std::snprintf could be el=
ided by a smart compiler; if the compiler knows that the only observable ef=
fect of std::snprintf is to modify "message", it could elide the =
call because std::unreachable is presumably implemented as an inline functi=
on.<br></div></blockquote><div><br></div><div>Correct. In optimized builds,=
std::unreachable() had darn well BETTER be equivalent to __builtin_unreach=
able().</div><div>In debug builds, a vendor might (unlikely IMO but possibl=
e) choose to print the given message and then abort. In that case, the call=
to std::snprintf could not be elided by the compiler, because its output w=
as actually being used.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">I was considering wording such as the follow=
ing, under the assumption that a runtime value of "message" is al=
lowed:<br><br>"If an implementation issues a diagnostic upon the execu=
tion of std::unreachable(), and the 'message' parameter is present,=
the diagnostic message should include the characters of 'message' =
that are in the execution character set."<br></div></blockquote><div><=
br></div><div>Assuming (correctly IMO) that the 'message' parameter=
is a `const char*`, it points to a null-terminated sequence of characters,=
which by definition are in the execution character set. The translation of=
a string literal (if any) from the source character set into a sequence of=
bytes in the execution character set has, by runtime, already happened; an=
d therefore std::unreachable() doesn't need to do anything special to d=
eal with it.</div><div><br></div><div>=E2=80=93Arthur</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/5a8666ef-278e-4636-baaa-8f71c5a54a2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a8666ef-278e-4636-baaa-8f71c5a54a2d=
%40isocpp.org</a>.<br />
------=_Part_12320_1597834854.1511410205888--
------=_Part_12319_1771334960.1511410205887--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 27 Nov 2017 12:36:34 -0800 (PST)
Raw View
------=_Part_25926_1965862028.1511814994894
Content-Type: multipart/alternative;
boundary="----=_Part_25927_1531922935.1511814994894"
------=_Part_25927_1531922935.1511814994894
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 22, 2017 at 8:10:06 PM UTC-8, Arthur O'Dwyer wrote:
>
>
> Assuming (correctly IMO) that the 'message' parameter is a `const char*`,=
=20
> it points to a null-terminated sequence of characters, which by definitio=
n=20
> are in the execution character set. The translation of a string literal (=
if=20
> any) from the source character set into a sequence of bytes in the=20
> execution character set has, by runtime, already happened; and therefore=
=20
> std::unreachable() doesn't need to do anything special to deal with it.
>
> =E2=80=93Arthur
>
Should I add a form that takes a std::string_view in addition to the const=
=20
char * form? Or only have a string_view form, since std::string_view has a=
=20
NUL-terminated const char * constructor?
Melissa
--=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/731b1b41-353c-4df7-bd25-2a2c1e6d628f%40isocpp.or=
g.
------=_Part_25927_1531922935.1511814994894
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 22, 2017 at 8:10:06 PM UTC-8, Arthu=
r O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div>Assuming (correctly IMO) that the 'message' param=
eter is a `const char*`, it points to a null-terminated sequence of charact=
ers, which by definition are in the execution character set. The translatio=
n of a string literal (if any) from the source character set into a sequenc=
e of bytes in the execution character set has, by runtime, already happened=
; and therefore std::unreachable() doesn't need to do anything special =
to deal with it.</div><div><br></div><div>=E2=80=93Arthur</div></div></bloc=
kquote><div><br></div><div>Should I add a form that takes a std::string_vie=
w in addition to the const char * form?=C2=A0 Or only have a string_view fo=
rm, since std::string_view has a NUL-terminated const char * constructor?</=
div><div><br></div><div>Melissa<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/731b1b41-353c-4df7-bd25-2a2c1e6d628f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/731b1b41-353c-4df7-bd25-2a2c1e6d628f=
%40isocpp.org</a>.<br />
------=_Part_25927_1531922935.1511814994894--
------=_Part_25926_1965862028.1511814994894--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 27 Nov 2017 12:56:25 -0800
Raw View
--089e082ebcc4b7566e055efd22c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 27, 2017 at 12:36 PM, Myriachan <myriachan@gmail.com> wrote:
> On Wednesday, November 22, 2017 at 8:10:06 PM UTC-8, Arthur O'Dwyer wrote=
:
>>
>>
>> Assuming (correctly IMO) that the 'message' parameter is a `const char*`=
,
>> it points to a null-terminated sequence of characters, which by definiti=
on
>> are in the execution character set. The translation of a string literal =
(if
>> any) from the source character set into a sequence of bytes in the
>> execution character set has, by runtime, already happened; and therefore
>> std::unreachable() doesn't need to do anything special to deal with it.
>>
>> =E2=80=93Arthur
>>
>
> Should I add a form that takes a std::string_view in addition to the cons=
t
> char * form? Or only have a string_view form, since std::string_view has=
a
> NUL-terminated const char * constructor?
>
My impression is that LEWG has been unfavorable to proposals that
complicate overload resolution for a name with both (const char*) and
(std::string_view) signatures. The (a?) problem is that it seems plausible
for a user-defined type to have implicit conversions to both types, in
which case the overload resolution would be ambiguous. There are well-known
solutions to the problem of "assigning priorities to otherwise ambiguous
overloads" (and Concepts will give us yet another solution)... but if we
avoid causing the problem, we don't even need to solve it.
I would confidently suggest that you should provide only (const char *), if
you feel the need for a message parameter at all. (I don't feel that need,
myself.)
- Consider that the expected input is that the user will pass a string
literal, which is exactly (const char *) and converting to string_view
would be superfluous.
- Consider that the expected usage-of-that-input is that the implementation
will pass it to fputs(stderr) or some other I/O mechanism on the same
approximate level of complexity as abort(). These I/O mechanisms often
natively take (const char *), and often cannot quite as easily handle
non-null-terminated (std::string_view).
The problem is not converting a null-terminated-byte-string to string_view;
the problem is converting a string_view into a null-terminated-byte-string
for consumption by the downstream C runtime. Similar considerations (but
more extreme) are why (Jonathan Wakely told me) that `int
std::svtoi(std::string_view)` will never happen. It would be useful
functionality to have, but it would be too complicated to implement.
`std::stoi` can (and does) just piggyback on top of `strtol`; but
`std::svtoi` would need a brand-new implementation that could handle
non-NTBS.
=E2=80=93Arthur
--=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/CADvuK0Kx%3D3tuEtpAQvs3D75%2BEJnR6ueeJ6vWzEzWBnr=
D7ByQeQ%40mail.gmail.com.
--089e082ebcc4b7566e055efd22c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Nov 27, 2017 at 12:36 PM, Myriachan <span dir=3D"l=
tr"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@=
gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=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">On Wednesday,=
November 22, 2017 at 8:10:06 PM UTC-8, Arthur O'Dwyer wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Assuming (correctly=
IMO) that the 'message' parameter is a `const char*`, it points to=
a null-terminated sequence of characters, which by definition are in the e=
xecution character set. The translation of a string literal (if any) from t=
he source character set into a sequence of bytes in the execution character=
set has, by runtime, already happened; and therefore std::unreachable() do=
esn't need to do anything special to deal with it.</div><div><br></div>=
<div>=E2=80=93Arthur</div></div></blockquote><div><br></div><div>Should I a=
dd a form that takes a std::string_view in addition to the const char * for=
m?=C2=A0 Or only have a string_view form, since std::string_view has a NUL-=
terminated const char * constructor?</div></div></blockquote><div><br></div=
><div>My impression is that LEWG has been unfavorable to proposals that com=
plicate overload resolution for a name with both (const char*) and (std::st=
ring_view) signatures. The (a?) problem is that it seems plausible for a us=
er-defined type to have implicit conversions to both types, in which case t=
he overload resolution would be ambiguous. There are well-known solutions t=
o the problem of "assigning priorities to otherwise ambiguous overload=
s" (and Concepts will give us yet another solution)... but if we avoid=
causing the problem, we don't even need to solve it.</div><div><br></d=
iv><div>I would confidently suggest that you should provide only (const cha=
r *), if you feel the need for a message parameter at all. (I don't fee=
l that need, myself.)</div><div>- Consider that the expected input is that =
the user will pass a string literal, which is exactly (const char *) and co=
nverting to string_view would be superfluous.</div><div>- Consider that the=
expected usage-of-that-input is that the implementation will pass it to fp=
uts(stderr) or some other I/O mechanism on the same approximate level of co=
mplexity as abort(). These I/O mechanisms often natively take (const char *=
), and often cannot quite as easily handle non-null-terminated (std::string=
_view).</div><div><br></div><div>The problem is not converting a null-termi=
nated-byte-string to string_view; the problem is converting a string_view i=
nto a null-terminated-byte-string for consumption by the downstream C runti=
me. Similar considerations (but more extreme) are why (Jonathan Wakely told=
me) that `int std::svtoi(std::string_view)` will never happen. It would be=
useful functionality to have, but it would be too complicated to implement=
.. `std::stoi` can (and does) just piggyback on top of `strtol`; but `std::s=
vtoi` would need a brand-new implementation that could handle non-NTBS.</di=
v><div><br></div><div>=E2=80=93Arthur</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/CADvuK0Kx%3D3tuEtpAQvs3D75%2BEJnR6uee=
J6vWzEzWBnrD7ByQeQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kx%3D3=
tuEtpAQvs3D75%2BEJnR6ueeJ6vWzEzWBnrD7ByQeQ%40mail.gmail.com</a>.<br />
--089e082ebcc4b7566e055efd22c0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 27 Nov 2017 15:53:22 -0800
Raw View
On Monday, 27 November 2017 12:56:25 PST Arthur O'Dwyer wrote:
> - Consider that the expected usage-of-that-input is that the implementation
> will pass it to fputs(stderr) or some other I/O mechanism on the same
> approximate level of complexity as abort(). These I/O mechanisms often
> natively take (const char *), and often cannot quite as easily handle
> non-null-terminated (std::string_view).
Actually, in this case it is easy to handle non-null-terminated:
fwrite(msg, msg.size(), 1, stderr);
But only in this one case. If you wanted to use one of many other logging
tools, like Win32's OutputDebugString(), syslog(), or sd_journal_send(), you'd
be right.
--
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/4204407.tFQ3njSWTE%40tjmaciei-mobl1.
.