[llvm] r200688 - Introduce SmallPtrSetImpl<T *> which allows insert, erase, count, and

Chandler Carruth chandlerc at gmail.com
Tue Feb 4 19:18:35 PST 2014


On Tue, Feb 4, 2014 at 5:00 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> >> We could be clever and have SmallFoo<T, N> inherit from SmallFoo<T> --
> if you
> >> pass the N you get the concrete derived type, if you don't, you get the
> basic
> >> functionality without a specific size. That is sadly the best (and
> worst!)
> >> idea I have....
> >
> > This might not be terrible, though it does make it a lot harder to talk
> > about the two different things.
>

I don't think it'll make it much harder. Realistically, all the things you
can do with a small vector, you can do with both, except for construction.
And the compiler will remind you of that. It's also a rare thing.


>
> The name overload of SmallFoo<T, N> and SmallFoo<T> is awesome.  But
> terrible.


Looking at the other options presented, it actually seems the least bad.
Specifically:

SmallFooUnsized<T> -- but it *has* a size. WTF?
SmallFooGen<T> -- but it doesn't generate anything.
SmallFooGeneric<T> -- what is more generic about this? (nothing)
SmallFooCommon<T> -- same as Impl, this is a totally unrelated suffix
BasicSmallFoo<T> -- Same as Impl on the other side but more confusing if
you're familiar with basic_string -- why is the non-basic *more* templated?
SmallFooSuper<T> -- C++ uses "super" very rarely to never. It's a base
class there. But we already have SmallVectorBase, arggg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140204/75b5a46e/attachment.html>


More information about the llvm-commits mailing list