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

[Duncan P. N. Exon Smith via llvm-dev]

> On 2020 Nov  25, at 22:55, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Am Mi., 25. Nov. 2020 um 17:52 Uhr schrieb David Blaikie via llvm-dev
> <llvm-dev at lists.llvm.org>:
>> I'm still not sure why "at least 1" is an important goal. I'd be
>> curious to hear from Chris/others why that's especially valuable.
> 
> If N is 0, then it's not a small-size optimized vector, in contrast to
> what the name implies.
> 
> Actually, if the intention is to have no inlined elements, I think one
> should use std:vector. Generally, projects should not reinvent STL
> containers and prefer the standard library one unless there is a good
> enough reason not to use them.

SmallVector<T, 0> has a number of benefits that make it better in practice than std::vector, at least for LLVM code:
- Interoperates with the pervasively used SmallVectorImpl<T>.
- No exception guarantees, and thus none of the related, harmful pessimizations (std::vector::resize will do expensive copies instead of cheap moves in some cases, last I checked).
- Customizations for using memcpy more often.
- Smaller by a pointer for most `T` (64-bit pointers).

Agreed that the name is wrong and not ergonomic, but we should not be using std::vector pretty much ever IMO.

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev