[PATCH] D18579: SetVector: Add front, pop_front and resize operations

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 31 15:36:04 PDT 2016


On Wed, Mar 30, 2016 at 3:31 PM, Matthias Braun via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> MatzeB added a comment.
>
> In http://reviews.llvm.org/D18579#386552, @dblaikie wrote:
>
> > Test cases?
> >  Got use cases in mind? (specific new/incoming patches to LLVM projects
> that
> >  will use this functionality)
>
>
> See http://reviews.llvm.org/D18427
>
> > & 'resize' seems like the wrong name for a set or map operation - perhaps
>
> >  "reserve"? (I think there was a recent change for this rename in
> DenseMap,
>
> >  right?)
>
>
> It is still called resize() in DenseSet, SmallPtrSet and BitVector so I'd
> like to keep that name for consistency. Of course someone else can rename
> them all to reserve() in the future.
>

BitVector, PackedVector, SmallBitVector, SmallVector, IndexedMap, and
DenseMap all have 'reserve'
BitVector, PackedVector, SmallBitVector, SmallVector, IndexedMap, DenseSet,
and ilist all have 'resize'

Looks like BitVector's resize and reserve are different (one just grows the
capacity, the other actually changes the size and adds unset bits) - as one
would expect.

PackedVector just delegates to its underlying BitVectorTy

SmallBitVector implements resize and reserve differently - like BItVector

SmallVector implements them differently, like std::vector, etc

IndexedMap delegates both

DenseMap has no resize, only reserve, which would be consistent with the
STL.

I don't see a resize in SmallPtrSet

Pretty sure the cases where resize actually means reserve are in the
minority & we'd want fewer rather than more.



>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D18579
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160331/e8936c48/attachment.html>


More information about the llvm-commits mailing list