[llvm-dev] RFC: [SmallVector] Adding SVec<T> and Vec<T> convenience wrappers.

[Chris Lattner via llvm-dev]

> On Dec 2, 2020, at 3:52 PM, David Blaikie <dblaikie at gmail.com> wrote:
> I’m pretty skeptical of #2 as an approach, because inline and out of line design points are pretty different when sizeof(T) is 4 or 8, and when sizeof(thevector) matters, e.g. in 2D cases.
> 
> To me, this is more like std::string, which is (2) - and more, to me, about the contract of the type - std::string doesn't guarantee iterator validity over swap/move, where std::vector does. If std::vector didn't have this guarantee, it'd be possible to have small vector optimizations in std::vector the same way std::string does - without the user-facing customization, mind you.

Yeah I definitely prefer to use standard types if we can, I think there is compelling upthread rationale for why using them in general causes complexity.  Maybe as future C++ standards improve we can drop them.  I hope someday that ArrayRef and StringRef can drop away in time for example.

> So I think (2) has some legs - but the problem for me is that if we name the type llvm::Vector, which already gets a bit close to std::vector (unqualified "Vector" seems like fairly subtle code to me - but I'm leaning towards being OK with that aspect if other peopel are) and it has different iterator invalidation/move semantics than std::vector, I think that could be problematic.

Not sure if I want to defend this, but we have lots of precedent for this, including llvm::sort etc.

llvm::Vector has some other nice but not compatible things, e.g. pop_back_val()

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/75623837/attachment.html>