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

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Feb 4 21:35:22 PST 2014


On 2014 Feb 4, at 19:18, Chandler Carruth <chandlerc at gmail.com> wrote:

> 
> 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.

SmallVectorBase is the obvious but unavailable choice.  Alas.

As strange as it is, I think your idea is better than the status quo.



More information about the llvm-commits mailing list