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

Justin Bogner mail at justinbogner.com
Tue Feb 4 16:06:06 PST 2014


Chandler Carruth <chandlerc at gmail.com> writes:
> On Tue, Feb 4, 2014 at 3:33 PM, Justin Bogner <mail at justinbogner.com> wrote:
>
>     Chandler Carruth <chandlerc at gmail.com> writes:
>     > Introduce SmallPtrSetImpl<T *> which allows insert, erase, count, and
>     > iteration. This alows the majority of operations to be performed without
>     > encoding a specific small size. It follows the model of
>     > SmallVectorImpl<T>.
>    
>     There's a lot to be said for following the existing practice, so feel
>     free to ignore this, but SmallVectorImpl isn't really a very indicative
>     name for how it's used in the first place. It's just ubiquitous enough
>     that it isn't worth changing. Maybe a better name from the get-go for
>     SmallPtrSetImpl would be worthwhile?
>    
>     On the other hand, it probably isn't worth bikeshedding about a perfect
>     name for this.
>
> I actually think a better name would be great, but I'd *much* rather
> consistency here given how thoroughly the current naming pattern has
> penetrated the codebases. For a sufficiently better name pattern I'd even be
> willing to broach the subject of switching the existing names over so that we
> can have the best of both worlds.
>
> The annoying thing is picking a substantially more clear name. Any ideas? I
> don't really have many.

If I had any good ideas I'd probably have mentioned them instead of just
complaining from the peanut gallery! One idea that amused me is
SmallishFoo, to indicate that it's less specific. Puns like that in
names are usually a bad sign though :)

I guess we'd want to go for something like UnspecifiedSmallFoo, but
that's getting to be a pretty long name.

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



More information about the llvm-commits mailing list