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

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Feb 4 17:00:58 PST 2014


On Feb 4, 2014, at 4:06 PM, Justin Bogner <mail at justinbogner.com> wrote:

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

As a new LLVM developer, the current misleading naming scheme has bothered me.
It would be great to be more clear here.

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

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

I’m not convinced these are any better, but they’re less misleading than
SmallFooImpl<T>:

- SmallFooUnsized<T>
- SmallFooGen<T> (or SmallFooGeneric<T> or GenericSmallFoo<T>)
- SmallFooCommon<T>
- BasicSmallFoo<T>





More information about the llvm-commits mailing list