Make strlen & strcmp constexpr?

[Thiago Macieira]

[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

[Daniel Krügler]

2017-03-06 11:24 GMT+01:00 Thiago Macieira <thi...@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

[Thiago Macieira]

Em segunda-feira, 6 de março de 2017, às 11:38:46 CET, Daniel Krügler
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.

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.

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

[Daniel Krügler]

2017-03-06 12:27 GMT+01:00 Thiago Macieira <thi...@macieira.org>:
> Em segunda-feira, 6 de março de 2017, às 11:38:46 CET, Daniel Krügler
> 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

[Thiago Macieira]

Em segunda-feira, 6 de março de 2017, às 12:45:53 CET, Daniel Krügler
escreveu:

> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thi...@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 was playing with using compiler extensions, but have yet to manage it. See
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.

[dgutson .]

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. See
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-pr...@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.

[Vishal Oza]

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 constexpr and have the global function not constexpr that should allow constexpr on C++ implementation of the C standard library.

[Ville Voutilainen]

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.

[Myriachan]

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

[Erich Keane]

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.

[Thiago Macieira]

Em terça-feira, 7 de março de 2017, às 00:22:10 CET, Erich Keane escreveu:
> In at least 2 of the major compilers, strlen and strcmp are implemented by
> builtins, which are constexpr.

True. Except that the case that turned this up was QStringView, that operates
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
(not to mention code bloat)

2) make QStringView constructor fast and reduce code bloat with an out-of-line
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
overloading on constexpr.

[Thiago Macieira]

Em segunda-feira, 6 de março de 2017, às 17:00:26 CET, Ville Voutilainen
escreveu:

> 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.

Should I then request a compiler extension?

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

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

[Thiago Macieira]

I don't see how C would be affected.

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

[Daniel Krügler]

2017-03-06 13:53 GMT+01:00 Thiago Macieira <thi...@macieira.org>:
> Em segunda-feira, 6 de março de 2017, às 12:45:53 CET, Daniel Krügler
> escreveu:
>> 2017-03-06 12:27 GMT+01:00 Thiago Macieira <thi...@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.

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

[Daniel Krügler]

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



--

________________________________
SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154
________________________________

[Thiago Macieira]

On sábado, 11 de março de 2017 04:51:14 PST Daniel Krügler wrote:
> 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

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

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

[T. C.]

Worth noting that P0202R1 is no longer proposing <cstring> modifications at all following discussion at a committee meeting.