[note: this is a leading question and I have an agenda]

In reviewing some code today, I noticed that the submitter included a
constexpr function:

        size_type result = 0;
        if (str) {
                while (*str++)
                        ++result;
        }
        return result;

So I went looking and found that std::char_traits does the same, as
string_view requires a constexpr length function. For example. in libc++:
 https://github.com/llvm-mirror/libcxx/blob/master/include/__string#L129

The same applies to std::char_traits::compare.

So, can we simply ask that <cstring> requires strlen, strcmp and strncmp be
constexpr? There could be a few others as well, like strchr, that could be
done so too.

--
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/1606529.H0hcDN3N30%40tjmaciei-mobl1.

.

2017-03-06 11:24 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> [note: this is a leading question and I have an agenda]
>
> In reviewing some code today, I noticed that the submitter included a
> constexpr function:
>
>         size_type result = 0;
>         if (str) {
>                 while (*str++)
>                         ++result;
>         }
>         return result;
>
> So I went looking and found that std::char_traits does the same, as
> string_view requires a constexpr length function. For example. in libc++:
>         https://github.com/llvm-mirror/libcxx/blob/master/include/__string#L129
>
> The same applies to std::char_traits::compare.
>
> So, can we simply ask that <cstring> requires strlen, strcmp and strncmp be
> constexpr? There could be a few others as well, like strchr, that could be
> done so too.

I think there will be possible resistance against touching C
functions. Why not instead using char_traits::compare,
char_traits::length, and char_traits::find, which are now required to
be constexpr (since p0426r1)?

- 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/CAGNvRgDcvbUnLz0UNnJzErqjcg%3D2MsHioQ8cmYKv3LuNtfQaBQ%40mail.gmail.com.

.

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 11:38:46 CET, Daniel Kr=
=C3=BCgler=20
escreveu:
> 2017-03-06 11:24 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > [note: this is a leading question and I have an agenda]
> >=20
> > In reviewing some code today, I noticed that the submitter included a
> >=20
> > constexpr function:
> >         size_type result =3D 0;
> >         if (str) {
> >        =20
> >                 while (*str++)
> >                =20
> >                         ++result;
> >        =20
> >         }
> >         return result;
> >=20
> > So I went looking and found that std::char_traits does the same, as
> >=20
> > string_view requires a constexpr length function. For example. in libc+=
+:
> >         https://github.com/llvm-mirror/libcxx/blob/master/include/__str=
ing
> >         #L129
> >=20
> > The same applies to std::char_traits::compare.
> >=20
> > So, can we simply ask that <cstring> requires strlen, strcmp and strncm=
p
> > be
> > constexpr? There could be a few others as well, like strchr, that could=
 be
> > done so too.
>=20
> I think there will be possible resistance against touching C
> functions. Why not instead using char_traits::compare,
> char_traits::length, and char_traits::find, which are now required to
> be constexpr (since p0426r1)?

Well, for three reasons:

1) I do expect other functions inherited from C to become constexpr, like=
=20
abs(), so we shouldn't be against doing this.

2) people know strlen() a lot more than std::char_traits<char>::length. I=
=20
didn't know it existed until I went searching, an hour ago.

3) and this is my agenda: strlen is SIMD-optimised,=20
std::char_traits<char>::length isn't.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1516770.q2Ce5ph6Xx%40tjmaciei-mobl1.

.

2017-03-06 12:27 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 11:38:46 CET, Daniel K=
r=C3=BCgler
> escreveu:
> Well, for three reasons:
>
> 1) I do expect other functions inherited from C to become constexpr, like
> abs(), so we shouldn't be against doing this.

I'm not seeing abs() yet to be constexpr, so this would depend on the
success of such a proposal. Could you refer to the paper that you were
(presumably) thinking of?

> 2) people know strlen() a lot more than std::char_traits<char>::length. I
> didn't know it existed until I went searching, an hour ago.

This is IMO not a very sufficient reason, because people can learn the
difference.

> 3) and this is my agenda: strlen is SIMD-optimised,
> std::char_traits<char>::length isn't.

Well, since SIMS optimization is not part of the standard, this seems
to be QoI anyway. Why not complaining to the vendor of your library to
ensure that std::char_traits<char>::length becomes SIMD-optimized,
too?

Note that I don't want to judge your request as use-less. I'm only
asking these questions, because similar questions will presumably be
asked when the Committee would inspect a corresponding paper.

Thanks,

- Daniel

--=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/CAGNvRgCphFSin1VjJ1fBjArB%2Bju2e2ac1G9Brot%3Dh9F=
TQNDDnA%40mail.gmail.com.

.

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 12:45:53 CET, Daniel Kr=
=C3=BCgler=20
escreveu:
> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > 1) I do expect other functions inherited from C to become constexpr, li=
ke
> > abs(), so we shouldn't be against doing this.
>=20
> I'm not seeing abs() yet to be constexpr, so this would depend on the
> success of such a proposal. Could you refer to the paper that you were
> (presumably) thinking of?

Sorry if I misled you: there is no such paper. My point is that std::abs=20
should be constexpr too. It's also an exampe of function that differs from =
C:=20
C's abs takes int; C++'s is overloaded on all integer and floating point ty=
pes.

> > 2) people know strlen() a lot more than std::char_traits<char>::length.=
 I
> > didn't know it existed until I went searching, an hour ago.
>=20
> This is IMO not a very sufficient reason, because people can learn the
> difference.

There shouldn't be a difference and in turn that should be sufficient reaso=
n.

> > 3) and this is my agenda: strlen is SIMD-optimised,
> > std::char_traits<char>::length isn't.
>=20
> Well, since SIMS optimization is not part of the standard, this seems
> to be QoI anyway. Why not complaining to the vendor of your library to
> ensure that std::char_traits<char>::length becomes SIMD-optimized,
> too?

Because you can't write SIMD code in constexpr functions. We need a way to=
=20
determine whether the function is being run constexprly or not.

I was playing with using compiler extensions, but have yet to manage it. Se=
e
https://godbolt.org/g/Dx5FKb

for an attempt (untested) with GCC builtins. I can't use the official funct=
ions=20
(not constexpr) and I can't write asm("") in that function...

> Note that I don't want to judge your request as use-less. I'm only
> asking these questions, because similar questions will presumably be
> asked when the Committee would inspect a corresponding paper.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/4981504.tEW6ppOXWH%40tjmaciei-mobl1.

.

--001a114dc58c6150e5054a0f7235
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 6/3/2017 9:53, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 12:45:53 CET, Daniel Kr=
=C3=BCgler
escreveu:
> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > 1) I do expect other functions inherited from C to become constexpr,
like
> > abs(), so we shouldn't be against doing this.
>
> I'm not seeing abs() yet to be constexpr, so this would depend on the
> success of such a proposal. Could you refer to the paper that you were
> (presumably) thinking of?

Sorry if I misled you: there is no such paper. My point is that std::abs
should be constexpr too. It's also an exampe of function that differs from
C:
C's abs takes int; C++'s is overloaded on all integer and floating point
types.

> > 2) people know strlen() a lot more than std::char_traits<char>::length.
I
> > didn't know it existed until I went searching, an hour ago.
>
> This is IMO not a very sufficient reason, because people can learn the
> difference.

There shouldn't be a difference and in turn that should be sufficient
reason.

> > 3) and this is my agenda: strlen is SIMD-optimised,
> > std::char_traits<char>::length isn't.
>
> Well, since SIMS optimization is not part of the standard, this seems
> to be QoI anyway. Why not complaining to the vendor of your library to
> ensure that std::char_traits<char>::length becomes SIMD-optimized,
> too?

Because you can't write SIMD code in constexpr functions. We need a way to
determine whether the function is being run constexprly or not.


I thought that overloading by constexpr was already planned. Am I wrong?
I mean provide two implementations, one constexpr and the other not, and
let the compiler choose.


I was playing with using compiler extensions, but have yet to manage it. Se=
e
https://godbolt.org/g/Dx5FKb

for an attempt (untested) with GCC builtins. I can't use the official
functions
(not constexpr) and I can't write asm("") in that function...

> Note that I don't want to judge your request as use-less. I'm only
> asking these questions, because similar questions will presumably be
> asked when the Committee would inspect a corresponding paper.

--
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/4981504.tEW6ppOXWH%40tjmaciei-mobl1.

--=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/CAFdMc-2oUa5AB3Yzy4MCWrkUk1TrPv2Afi59nmmRbC4qHL8=
2fA%40mail.gmail.com.

--001a114dc58c6150e5054a0f7235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">El 6/3/2017 9:53, &quot;Thiago Macieira&quot; &lt;<a href=3D"mail=
to:thiago@macieira.org">thiago@macieira.org</a>&gt; escribi=C3=B3:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Em segunda-feira, 6 de mar=C3=A7o=
 de 2017, =C3=A0s 12:45:53 CET, Daniel Kr=C3=BCgler<br>
escreveu:<br>
<div class=3D"quoted-text">&gt; 2017-03-06 12:27 GMT+01:00 Thiago Macieira =
&lt;<a href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt;:<br>
</div><div class=3D"quoted-text">&gt; &gt; 1) I do expect other functions i=
nherited from C to become constexpr, like<br>
&gt; &gt; abs(), so we shouldn&#39;t be against doing this.<br>
&gt;<br>
&gt; I&#39;m not seeing abs() yet to be constexpr, so this would depend on =
the<br>
&gt; success of such a proposal. Could you refer to the paper that you were=
<br>
&gt; (presumably) thinking of?<br>
<br>
</div>Sorry if I misled you: there is no such paper. My point is that std::=
abs<br>
should be constexpr too. It&#39;s also an exampe of function that differs f=
rom C:<br>
C&#39;s abs takes int; C++&#39;s is overloaded on all integer and floating =
point types.<br>
<div class=3D"quoted-text"><br>
&gt; &gt; 2) people know strlen() a lot more than std::char_traits&lt;char&=
gt;::<wbr>length. I<br>
&gt; &gt; didn&#39;t know it existed until I went searching, an hour ago.<b=
r>
&gt;<br>
&gt; This is IMO not a very sufficient reason, because people can learn the=
<br>
&gt; difference.<br>
<br>
</div>There shouldn&#39;t be a difference and in turn that should be suffic=
ient reason.<br>
<div class=3D"quoted-text"><br>
&gt; &gt; 3) and this is my agenda: strlen is SIMD-optimised,<br>
&gt; &gt; std::char_traits&lt;char&gt;::length isn&#39;t.<br>
&gt;<br>
&gt; Well, since SIMS optimization is not part of the standard, this seems<=
br>
&gt; to be QoI anyway. Why not complaining to the vendor of your library to=
<br>
&gt; ensure that std::char_traits&lt;char&gt;::length becomes SIMD-optimize=
d,<br>
&gt; too?<br>
<br>
</div>Because you can&#39;t write SIMD code in constexpr functions. We need=
 a way to<br>
determine whether the function is being run constexprly or not.<br></blockq=
uote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I thou=
ght that overloading by constexpr was already planned. Am I wrong?</div><di=
v dir=3D"auto">I mean provide two implementations, one constexpr and the ot=
her not, and let the compiler choose.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<br>
I was playing with using compiler extensions, but have yet to manage it. Se=
e<br>
<a href=3D"https://godbolt.org/g/Dx5FKb" rel=3D"noreferrer" target=3D"_blan=
k">https://godbolt.org/g/Dx5FKb</a><br>
<br>
for an attempt (untested) with GCC builtins. I can&#39;t use the official f=
unctions<br>
(not constexpr) and I can&#39;t write asm(&quot;&quot;) in that function...=
<br>
<div class=3D"quoted-text"><br>
&gt; Note that I don&#39;t want to judge your request as use-less. I&#39;m =
only<br>
&gt; asking these questions, because similar questions will presumably be<b=
r>
&gt; asked when the Committee would inspect a corresponding paper.<br>
<br>
</div><div class=3D"quoted-text">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</div><div class=3D"quoted-text">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/4981504.tEW6ppOXWH%40tjmaciei-m=
obl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msgid/std-<wbr>proposals/4981504.tEW6ppOXWH%<wbr>40tjmaciei-m=
obl1</a>.<br>
</blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAFdMc-2oUa5AB3Yzy4MCWrkUk1TrPv2Afi59=
nmmRbC4qHL82fA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2oUa5AB3Yz=
y4MCWrkUk1TrPv2Afi59nmmRbC4qHL82fA%40mail.gmail.com</a>.<br />

--001a114dc58c6150e5054a0f7235--

.

------=_Part_9120_1025865167.1488809394757
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would still be concerned with breakage of C code and not with C++. Althou=
ght if you wrap the functions in the standard namespace as constexpr  and h=
ave the global function not constexpr that should allow constexpr on C++ im=
plementation of the C standard library.

--=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/d5f06c6b-6026-4cf4-8452-f28f023cb329%40isocpp.or=
g.

------=_Part_9120_1025865167.1488809394757--

.

On 6 March 2017 at 14:58, dgutson . <danielgutson@gmail.com> wrote:
> I thought that overloading by constexpr was already planned. Am I wrong?

There is no such plan.

--
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/CAFk2RUbrS-XvGeCHiQ076zjZwxP6bvOOR6f%3Dq68fY2Os%2BPgRdA%40mail.gmail.com.

.

------=_Part_6088_1261084522.1488832156843
Content-Type: multipart/alternative;
 boundary="----=_Part_6089_591423244.1488832156844"

------=_Part_6089_591423244.1488832156844
Content-Type: text/plain; charset=UTF-8

On Monday, March 6, 2017 at 8:06:03 AM UTC-8, Ville Voutilainen wrote:
>
> On 6 March 2017 at 14:58, dgutson . <daniel...@gmail.com <javascript:>>
> wrote:
> > I thought that overloading by constexpr was already planned. Am I wrong?
>
> There is no such plan.
>

To me, this is the dealbreaker with Thiago's proposal.  Modern strcmp is
implemented as SSE4.2 assembly language or similar vector craziness on
other platforms.  How could we simultaneously get the performance benefit
of optimized strcmp and having it constexpr without such overloading?

Sure, compiler magic could replace calls to strcmp with calls to the SSE4.2
code, but that's effectively the same thing as having overloading.  I
suspect that GCC and clang's headers would use __builtin_constant_p in the
strcmp definition in <cstring>.

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/5d82fdb1-b7fa-4453-903f-83d50ba4e9db%40isocpp.org.

------=_Part_6089_591423244.1488832156844
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 6, 2017 at 8:06:03 AM UTC-8, Ville Voutil=
ainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6 March 2017 at=
 14:58, dgutson . &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"MNpWYxo-CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">daniel...@gmail.com</a>&gt; wrote:
<br>&gt; I thought that overloading by constexpr was already planned. Am I =
wrong?
<br>
<br>There is no such plan.
<br></blockquote><div><br>To me, this is the dealbreaker with Thiago&#39;s =
proposal.=C2=A0 Modern strcmp is implemented as SSE4.2 assembly language or=
 similar vector craziness on other platforms.=C2=A0 How could we simultaneo=
usly get the performance benefit of optimized strcmp and having it constexp=
r without such overloading?<br><br>Sure, compiler magic could replace calls=
 to strcmp with calls to the SSE4.2 code, but that&#39;s effectively the sa=
me thing as having overloading.=C2=A0 I suspect that GCC and clang&#39;s he=
aders would use __builtin_constant_p in the strcmp definition in &lt;cstrin=
g&gt;.<br><br>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&quot; 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/5d82fdb1-b7fa-4453-903f-83d50ba4e9db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d82fdb1-b7fa-4453-903f-83d50ba4e9db=
%40isocpp.org</a>.<br />

------=_Part_6089_591423244.1488832156844--

------=_Part_6088_1261084522.1488832156843--

.

------=_Part_7034_594225996.1488842530992
Content-Type: multipart/alternative;
 boundary="----=_Part_7035_1923634818.1488842530993"

------=_Part_7035_1923634818.1488842530993
Content-Type: text/plain; charset=UTF-8

In at least 2 of the major compilers, strlen and strcmp are implemented by
builtins, which are constexpr.

In fact, the code for 'strlen' and __builtin_strlen in clang are identical
paths, except for an error issued on the former (due to it not being
constexpr).

Both strcmp/strlen would be pretty awesome to be constexpr, both already
use compiler magic for each, so it wouldn't be an issue.  However, LEWG
seems to show some resistance to marking C-libraries constexpr, and this
would require changing THAT decision.



On Monday, March 6, 2017 at 12:29:17 PM UTC-8, Myriachan wrote:
>
> On Monday, March 6, 2017 at 8:06:03 AM UTC-8, Ville Voutilainen wrote:
>>
>> On 6 March 2017 at 14:58, dgutson . <daniel...@gmail.com> wrote:
>> > I thought that overloading by constexpr was already planned. Am I
>> wrong?
>>
>> There is no such plan.
>>
>
> To me, this is the dealbreaker with Thiago's proposal.  Modern strcmp is
> implemented as SSE4.2 assembly language or similar vector craziness on
> other platforms.  How could we simultaneously get the performance benefit
> of optimized strcmp and having it constexpr without such overloading?
>
> Sure, compiler magic could replace calls to strcmp with calls to the
> SSE4.2 code, but that's effectively the same thing as having overloading.
> I suspect that GCC and clang's headers would use __builtin_constant_p in
> the strcmp definition in <cstring>.
>
> 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/858b89bd-60e7-479d-aa3f-b62b0eccc8d4%40isocpp.org.

------=_Part_7035_1923634818.1488842530993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In at least 2 of the major compilers, strlen and strcmp ar=
e implemented by builtins, which are constexpr.<br><br>In fact, the code fo=
r &#39;strlen&#39; and __builtin_strlen in clang are identical paths, excep=
t for an error issued on the former (due to it not being constexpr).<br><br=
>Both strcmp/strlen would be pretty awesome to be constexpr, both already u=
se compiler magic for each, so it wouldn&#39;t be an issue.=C2=A0 However, =
LEWG seems to show some resistance to marking C-libraries constexpr, and th=
is would require changing THAT decision.<br><br><br><br>On Monday, March 6,=
 2017 at 12:29:17 PM UTC-8, Myriachan wrote:<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">On Monday, March 6, 2017 at 8:06:03 AM UTC-8=
, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 Marc=
h 2017 at 14:58, dgutson . &lt;<a rel=3D"nofollow">daniel...@gmail.com</a>&=
gt; wrote:
<br>&gt; I thought that overloading by constexpr was already planned. Am I =
wrong?
<br>
<br>There is no such plan.
<br></blockquote><div><br>To me, this is the dealbreaker with Thiago&#39;s =
proposal.=C2=A0 Modern strcmp is implemented as SSE4.2 assembly language or=
 similar vector craziness on other platforms.=C2=A0 How could we simultaneo=
usly get the performance benefit of optimized strcmp and having it constexp=
r without such overloading?<br><br>Sure, compiler magic could replace calls=
 to strcmp with calls to the SSE4.2 code, but that&#39;s effectively the sa=
me thing as having overloading.=C2=A0 I suspect that GCC and clang&#39;s he=
aders would use __builtin_constant_p in the strcmp definition in &lt;cstrin=
g&gt;.<br><br>Melissa<br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/858b89bd-60e7-479d-aa3f-b62b0eccc8d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/858b89bd-60e7-479d-aa3f-b62b0eccc8d4=
%40isocpp.org</a>.<br />

------=_Part_7035_1923634818.1488842530993--

------=_Part_7034_594225996.1488842530992--

.

Em ter=C3=A7a-feira, 7 de mar=C3=A7o de 2017, =C3=A0s 00:22:10 CET, Erich K=
eane escreveu:
> In at least 2 of the major compilers, strlen and strcmp are implemented b=
y
> builtins, which are constexpr.

True. Except that the case that turned this up was QStringView, that operat=
es=20
on UTF-16. So we can't use __builtin_strlen.

Right now, we're faced with having to choose between:

1) make the QStringView constructor constexpr, but possibly slow on runtime=
=20
(not to mention code bloat)

2) make QStringView constructor fast and reduce code bloat with an out-of-l=
ine=20
function, but drop the constexpr aspect.

I'm leaning towards #2.

> Both strcmp/strlen would be pretty awesome to be constexpr, both already
> use compiler magic for each, so it wouldn't be an issue.  However, LEWG
> seems to show some resistance to marking C-libraries constexpr, and this
> would require changing THAT decision.

I'm hoping it would. But even if LEWG keeps its stance, I'd still need=20
overloading on constexpr.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/48029441.V5FE4FrRz1%40tjmaciei-mobl1.

.

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 17:00:26 CET, Ville Vout=
ilainen=20
escreveu:
> On 6 March 2017 at 14:58, dgutson . <danielgutson@gmail.com> wrote:
> > I thought that overloading by constexpr was already planned. Am I wrong=
?
>=20
> There is no such plan.

Should I then request a compiler extension?

After all, intrisincs and asm() are compiler extensions too, so any benefit=
=20
above and beyond the constexpr code almost necessarily requires compiler=20
extensions anyway.

PS: then we'll have to ask that all compilers implement the same extension,=
=20
with the same name and semantics. I think that process is called=20
"standardisation"... if only C++ had an official way of doing that...

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/2317688.z3Tmb3h35d%40tjmaciei-mobl1.

.

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 15:09:54 CET, Vishal Oza=
 escreveu:
> I would still be concerned with breakage of C code and not with C++.
> Althought if you wrap the functions in the standard namespace as constexp=
r=20
> and have the global function not constexpr that should allow constexpr on
> C++ implementation of the C standard library.

I don't see how C would be affected.

If the solution we provide is to add a constexpr *overload*, then it's no=
=20
different than std::abs.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1678850.mpvEkfyQU6%40tjmaciei-mobl1.

.

2017-03-06 13:53 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 12:45:53 CET, Daniel K=
r=C3=BCgler
> escreveu:
>> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
>> > 1) I do expect other functions inherited from C to become constexpr, l=
ike
>> > abs(), so we shouldn't be against doing this.
>>
>> I'm not seeing abs() yet to be constexpr, so this would depend on the
>> success of such a proposal. Could you refer to the paper that you were
>> (presumably) thinking of?
>
> Sorry if I misled you: there is no such paper. My point is that std::abs
> should be constexpr too. It's also an exampe of function that differs fro=
m C:
> C's abs takes int; C++'s is overloaded on all integer and floating point =
types.

Actually, you didn't mislead me, the paper that I didn't remind at the
time of my response was this one:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0533r0.pdf

I suggest to refer that in future discussions.

Thanks,

- Daniel

--=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/CAGNvRgBdeHahzu_4YRyeroFYRFDGFoXSC6iLENgZs1sBP7G=
Bfw%40mail.gmail.com.

.

2017-03-11 13:45 GMT+01:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
> 2017-03-06 13:53 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
>> Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 12:45:53 CET, Daniel =
Kr=C3=BCgler
>> escreveu:
>>> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
>>> > 1) I do expect other functions inherited from C to become constexpr, =
like
>>> > abs(), so we shouldn't be against doing this.
>>>
>>> I'm not seeing abs() yet to be constexpr, so this would depend on the
>>> success of such a proposal. Could you refer to the paper that you were
>>> (presumably) thinking of?
>>
>> Sorry if I misled you: there is no such paper. My point is that std::abs
>> should be constexpr too. It's also an exampe of function that differs fr=
om C:
>> C's abs takes int; C++'s is overloaded on all integer and floating point=
 types.
>
> Actually, you didn't mislead me, the paper that I didn't remind at the
> time of my response was this one:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0533r0.pdf
>
> I suggest to refer that in future discussions.

Here another one, nearer to your original request, which makes
suggestions to add constexpr functions to <cstring> and similar C
headers:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html

Actually this paper is what you are looking for ;-)

> Thanks,
>
> - Daniel



--=20

________________________________
SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4ilL=
E.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD=
-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1395770=
800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2=
fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0=
_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1=
395770800154
________________________________

--=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/CAGNvRgDE93a%3DzZJBJOtRaLy042aOe9Har_u_fnZ4%3DZW=
d-bg-mA%40mail.gmail.com.

.

On s=C3=A1bado, 11 de mar=C3=A7o de 2017 04:51:14 PST Daniel Kr=C3=BCgler w=
rote:
> Here another one, nearer to your original request, which makes
> suggestions to add constexpr functions to <cstring> and similar C
> headers:
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html
>=20
> Actually this paper is what you are looking for=20

indeed, strchr was one of the functions I was thinking of as well, since it=
's=20
extremely efficient to implement it with SSE.

The paper only asks for making <cstring> functions constexpr that Standard=
=20
algorithms apparently need. That means it doesn't go far enough in=20
recommending modifications along the line of P0533R0. I think it should.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/2752972.XPseaFQjvX%40tjmaciei-mobl1.

.

------=_Part_1568_1735270843.1489270498702
Content-Type: multipart/alternative;
 boundary="----=_Part_1569_1483603632.1489270498702"

------=_Part_1569_1483603632.1489270498702
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Saturday, March 11, 2017 at 11:37:49 AM UTC-5, Thiago Macieira wrote:
>
> On s=C3=A1bado, 11 de mar=C3=A7o de 2017 04:51:14 PST Daniel Kr=C3=BCgler=
 wrote:=20
> > Here another one, nearer to your original request, which makes=20
> > suggestions to add constexpr functions to <cstring> and similar C=20
> > headers:=20
> >=20
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html=20
> >=20
> > Actually this paper is what you are looking for=20
>
> indeed, strchr was one of the functions I was thinking of as well, since=
=20
> it's=20
> extremely efficient to implement it with SSE.=20
>
> The paper only asks for making <cstring> functions constexpr that Standar=
d=20
> algorithms apparently need. That means it doesn't go far enough in=20
> recommending modifications along the line of P0533R0. I think it should.=
=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>
Worth noting that P0202R1 is no longer proposing <cstring> modifications at=
=20
all following discussion at a committee meeting.

--=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/6e8ebd95-1ac2-49a8-bdbc-de4fb38f54f2%40isocpp.or=
g.

------=_Part_1569_1483603632.1489270498702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, March 11, 2017 at 11:37:49 AM UTC-5, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=
=A1bado, 11 de mar=C3=A7o de 2017 04:51:14 PST Daniel Kr=C3=BCgler wrote:
<br>&gt; Here another one, nearer to your original request, which makes
<br>&gt; suggestions to add constexpr functions to &lt;cstring&gt; and simi=
lar C
<br>&gt; headers:
<br>&gt;=20
<br>&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0202r0.html" 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=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0202r0.html\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNFf0efEFAWwGSQVICWDYBAe3Qp3hg&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0202r0.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFf0efEFAWwGSQVICWDYBAe3Qp3hg&#39;;return tru=
e;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0202=
r0.html</a>
<br>&gt;=20
<br>&gt; Actually this paper is what you are looking for=20
<br>
<br>indeed, strchr was one of the functions I was thinking of as well, sinc=
e it&#39;s=20
<br>extremely efficient to implement it with SSE.
<br>
<br>The paper only asks for making &lt;cstring&gt; functions constexpr that=
 Standard=20
<br>algorithms apparently need. That means it doesn&#39;t go far enough in=
=20
<br>recommending modifications along the line of P0533R0. I think it should=
..
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>Worth noting that P0202R1 is no longer=
 proposing &lt;cstring&gt; modifications at all following discussion at a c=
ommittee meeting.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/6e8ebd95-1ac2-49a8-bdbc-de4fb38f54f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e8ebd95-1ac2-49a8-bdbc-de4fb38f54f2=
%40isocpp.org</a>.<br />

------=_Part_1569_1483603632.1489270498702--

------=_Part_1568_1735270843.1489270498702--

.