[llvm] r221960 - IR: Rewrite uniquing and creation of MDString
David Blaikie
dblaikie at gmail.com
Tue Nov 18 11:52:39 PST 2014
On Tue, Nov 18, 2014 at 11:19 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
>
> > On 2014 Nov 18, at 10:06, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Unexposed, but not magic - it can be implemented in LLVM as it is in
> libc++. A few of these utilities are a bit of a pain to write, but they're
> generic enough not to need to be written very often.
>
> This is spiraling into a major project :). I just want to pass in
> a context by reference to prevent reference/pointer disagreement
> in `MDString::get()` vs. `MDString::MDString()`, so I want some
> API that is clear and correct.
>
I'm not sure it's so clear when this can invoke explicit ctors in a context
where one would only really expect implicit conversions. Maybe for this use
case it's not problematic, but for others this could be a pretty confusing
stumbling block/bug.
> How about I file a PR for this? Your argument that `emplace()`
> would be a good abstraction here is convincing, but encapsulating
> `StringMap` is pretty orthogonal to my current work.
>
If you don't have time to address this now, I'll find some & just do it - I
don't really want this implicit invocation of explicit ctors sticking
around.
> In the meantime, I think the perfect-forwarding I added in the
> 3-arg version of `StringMapEntry::Create()` is an incremental
> improvement.
I don't think this is an incremental improvement since it can lead to
explicit ctors being called essentially implicitly.
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141118/87f60b3b/attachment.html>
More information about the llvm-commits
mailing list