[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