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

[Mehdi AMINI via llvm-dev]

On Mon, Nov 30, 2020 at 9:02 PM Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Am Mo., 30. Nov. 2020 um 19:34 Uhr schrieb Duncan P. N. Exon Smith
> <dexonsmith at apple.com>:r<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).
>
> The LLVM project also hosts libc++, shouldn't we dogfood our own
> implementations?
>

std::vector is limited by what the standard allows though. In particular in
terms of exception safety (IIRC you can't use -fnoexception to change the
behavior like moving instead of copying in general).


>
> 2 and 3 should be optimizations possible in the STL. I disagree that
> SmallVectorImpl is pervasively used.


Any method that accepts a container and will do something like "push_back"
on it has to either take SmallVectorImpl or be templated to accept
std::vector and SmallVector.


> The normal use case is a function
> parameter where the caller creates a SmallVector just to pass it, and
> can continue to do so with zero inline elements even if in other
> places we use std::vector.
>
> Michael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/49e22a8c/attachment.html>