[llvm-dev] RFC: Constructing StringRefs at compile time

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 24 07:04:13 PST 2016


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


More information about the llvm-dev mailing list