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

[Zachary Turner via llvm-dev]

If we have a macro and a UDL, is there any risk of any of these issues
anyway?  We could hide the UDL under a details namespace and expose a macro
that "just works".

But that begs the question -- is there any way to invoke a UDL that is not
visible in the current namespace?  can you explicitly qualify it?

On Tue, Nov 29, 2016 at 9:56 AM David Blaikie <dblaikie at gmail.com> wrote:

> 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/b9c5f666/attachment.html>