Displaying 5 results from an estimated 5 matches for "llvm_strlen".
2016 Nov 29
4
RFC: Constructing StringRefs at compile time
On 29 November 2016 at 17:38, Zachary Turner <zturner at google.com> wrote:
> I see, but I looked over your proposed implementation from earlier in the
> thread, and if I'm not mistaken I see this:
That's a different suggestion.
> That said, what did you think about my other proposal of the complicated UDL
> with macro?
>
> #define LIT(x) x_string_ref_literal
>
2016 Nov 29
2
RFC: Constructing StringRefs at compile time
...lt;llvm-dev at lists.llvm.org> wrote:
> The basic idea here is that you introduce a StringLiteral class and anywhere
> you want to use a global constructor, you make sure to declare a constexpr
> array instead of a normal array, and you make it of type StringLiteral.
I prefer constexpr llvm_strlen() over StringLiteral because it doesn't
require code changes outside StringRef - all StringRefs constructed
from a literal can benefit. But there are concerns about MSVC.
I prefer StringLiteral over UDL because the type requires code
changes, but the values don't.
I prefer StringLiteral ov...
2016 Nov 29
2
RFC: Constructing StringRefs at compile time
On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote:
> I don't like the llvm_strlen approach as it is incompatible with
> std::string_view which we may eventually move to.
In what way is it incompatible?
constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {}
is equivalent to
constexpr string_view(const char* s) : Data(s),
Length(std::char_traits<char>::...
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
The fact that the templatized constructor falls down because of the
possibility of initializing StringRef with a stack-allocated char array
kills that idea in my mind.
I feel like the only two reasonable solutions are
1) allow UDL for this case, document that this is an exception and that
UDLs are still not permitted anywhere else, and require (by policy, since I
don't know of a way to have