Displaying 4 results from an estimated 4 matches for "d25639".
Did you mean:
25639
2016 Nov 24
3
RFC: Constructing StringRefs at compile time
...s 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...
2016 Nov 29
2
RFC: Constructing StringRefs at compile time
...tarted with: "There is a desire to be able to create constexpr
> StringRefs to avoid static initializers for global tables of/containing
> StringRefs.”
>
> I don’t have more information, but maybe Malcolm can elaborate?
I was restating your motivation from https://reviews.llvm.org/D25639.
--
Malcolm Parsons
2016 Nov 25
5
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
2016 Nov 28
3
RFC: Constructing StringRefs at compile time
On Mon, Nov 28, 2016 at 11:01 AM Mehdi Amini <mehdi.amini at apple.com> wrote:
> On Nov 28, 2016, at 9:47 AM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> OK - good to know. (not sure we're talking about pessimizing it - just not
> adding a new/possible optimization, to be clear)
>
>
> This does not seem that clear to me. The