llvm dev - Nov 2016 - RFC: Constructing StringRefs at compile time

Hi all,

There is a desire to be able to create constexpr StringRefs to avoid
static initializers for global tables of/containing StringRefs.

Creating constexpr StringRefs isn't trivial as strlen isn't portably
constexpr and std::char_traits<char>::length is only constexpr in
C++17.

Alp Toker tried to create constexpr StringRefs for strings literals by
subclassing StringRef:
https://reviews.llvm.org/rL200187
This is a verbose change where needed at string literal call sites.

Mehdi AMINI tried to add a constexpr constructor for string literals
by making the constructor from const char * explicit:
https://reviews.llvm.org/D25639
This is a verbose change at every non-literal call site.
This only works with assignment syntax.

I've suggested using a user-defined literal:
https://reviews.llvm.org/D26332
This is a small change where needed at string literal call sites.
C++17 adds a UDL for std::string_view, so it's not an unusual idea.
There is resistance to using a UDL as they can introduce a surprising
and novel syntax for calling functions.

Comments?

Other options?

Thanks,
-- 
Malcolm Parsons

----- Original Message -----
> From: "Malcolm Parsons via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Thursday, November 24, 2016 8:59:25 AM
> Subject: [llvm-dev] RFC: Constructing StringRefs at compile time
> 
> Hi all,
> 
> There is a desire to be able to create constexpr StringRefs to avoid
> static initializers for global tables of/containing StringRefs.
> 
> Creating constexpr StringRefs isn't trivial as strlen isn't
portably
> constexpr and std::char_traits<char>::length is only constexpr in
> C++17.
Why don't we just create our own traits class that has a constexpr length,
and then we can switch over to the standard one when we switch to C++17?

 -Hal
> 
> Alp Toker tried to create constexpr StringRefs for strings literals
> by
> subclassing StringRef:
> https://reviews.llvm.org/rL200187
> This is a verbose change where needed at string literal call sites.
> 
> Mehdi AMINI tried to add a constexpr constructor for string literals
> by making the constructor from const char * explicit:
> https://reviews.llvm.org/D25639
> This is a verbose change at every non-literal call site.
> This only works with assignment syntax.
> 
> I've suggested using a user-defined literal:
> https://reviews.llvm.org/D26332
> This is a small change where needed at string literal call sites.
> C++17 adds a UDL for std::string_view, so it's not an unusual idea.
> There is resistance to using a UDL as they can introduce a surprising
> and novel syntax for calling functions.
> 
> Comments?
> 
> Other options?
> 
> Thanks,
> --
> Malcolm Parsons
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov>
wrote:
>> Creating constexpr StringRefs isn't trivial as strlen isn't
portably
>> constexpr and std::char_traits<char>::length is only constexpr in
>> C++17.
>
> Why don't we just create our own traits class that has a constexpr
length, and then we can switch over to the standard one when we switch to C++17?
GCC and Clang treat __builtin_strlen as constexpr.
MSVC 2015 doesn't support C++14 extended constexpr. I don't know how
well it optimises a recursive strlen.

This works as an optimisation for GCC and Clang, and doesn't make
things worse for MSVC:

     /// Construct a string ref from a cstring.
     LLVM_ATTRIBUTE_ALWAYS_INLINE
+#if __has_builtin(__builtin_strlen)
+    /*implicit*/ constexpr StringRef(const char *Str)
+        : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {}
+#else
     /*implicit*/ StringRef(const char *Str)
         : Data(Str), Length(Str ? ::strlen(Str) : 0) {}
+#endif

-- 
Malcolm Parsons

We could probably write and use our own constexpr strlen for MSVC, but we'd
lose out on the CRT's optimized implementation of strlen.

On Thu, Nov 24, 2016 at 6:59 AM, Malcolm Parsons via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> There is a desire to be able to create constexpr StringRefs to avoid
> static initializers for global tables of/containing StringRefs.
>
> Creating constexpr StringRefs isn't trivial as strlen isn't
portably
> constexpr and std::char_traits<char>::length is only constexpr in
> C++17.
>
> Alp Toker tried to create constexpr StringRefs for strings literals by
> subclassing StringRef:
> https://reviews.llvm.org/rL200187
> This is a verbose change where needed at string literal call sites.
>
> Mehdi AMINI tried to add a constexpr constructor for string literals
> by making the constructor from const char * explicit:
> https://reviews.llvm.org/D25639
> This is a verbose change at every non-literal call site.
> This only works with assignment syntax.
>
> I've suggested using a user-defined literal:
> https://reviews.llvm.org/D26332
> This is a small change where needed at string literal call sites.
> C++17 adds a UDL for std::string_view, so it's not an unusual idea.
> There is resistance to using a UDL as they can introduce a surprising
> and novel syntax for calling functions.
>
> Comments?
>
> Other options?
>
> Thanks,
> --
> Malcolm Parsons
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161125/d3e8b58a/attachment.html>