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

[Reid Kleckner via llvm-dev]

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>