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

[Mehdi Amini via llvm-dev]

> On Nov 25, 2016, at 6:10 AM, Mueller-Roemer, Johannes Sebastian via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> What about going for
> 
> template<unsigned N>
> constexpr StringRef(const char (&Str)[N])
> 
> and avoiding strlen entirely for string literals?

We are allowing currently an explicit null char in the middle of a literal.

That’s why I had the constructor you mentioned but not using N for the length here: https://reviews.llvm.org/D25639#497ba4c0

However this does not help with a construct like:


const char Arr[32];
fill(Arr);
StringRef S(Arr);

— 
Mehdi



> 
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Malcolm Parsons via llvm-dev
> Sent: Friday, November 25, 2016 13:34
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC: Constructing StringRefs at compile time
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev