[llvm-dev] RFC: Constructing StringRefs at compile time
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 29 09:56:15 PST 2016
Honestly, if we just use something like that macro - we could define it
in-situ for each table separately. Then there's less risk of any
interesting cases like large buffers, embedded nulls, etc. (it's limited in
scope and obvious at the use what the limitations of the macro are, etc)
On Tue, Nov 29, 2016 at 9:55 AM Zachary Turner <zturner at google.com> wrote:
> char buffer[100];
> And it also allows LIT(buffer) to compile, whereas the UDL doesn't.
>
> On Tue, Nov 29, 2016 at 9:54 AM Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>
> > On Nov 29, 2016, at 9:52 AM, Malcolm Parsons <malcolm.parsons at gmail.com>
> wrote:
> >
> > 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
> >> constexpr StringRef Strings[] = {LIT("a"), LIT("b"), LIT("c")};
> >
> > Why bother with the UDL?
> > #define LIT(x) StringRef((x), sizeof(x)-1)
> >
>
> There is subtlety though, it changes the result for: LIT(“hello\0world”).
>
> —
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161129/82048052/attachment.html>
More information about the llvm-dev
mailing list