[llvm-dev] ArrayRef vs SmallVectorImpl

Russell Wallace via llvm-dev llvm-dev at lists.llvm.org
Fri May 3 09:46:41 PDT 2019

Ah, so ArrayRef is strictly preferable only to const SmallVectorImpl&.
Makes sense, thanks!

On Fri, May 3, 2019 at 5:42 PM David Blaikie <dblaikie at gmail.com> wrote:

> The documentation might be specifically calling out the non-const
> SmallVector ref case. That would be the case wheer you want to modify
> the vector or its contents.
> If you don't want to do any mutation and the container can't change
> underneath you (eg: nothing happening inside the function might cause,
> indirectly, the vector to be resized, etc) then ArrayRef is probably
> the right tool.
> If you want to modify the existing elements of the container (&
> similarly, the vector won't be resized, etc) - MutableArrayRef would
> be suitable.
> If you need to be able to add or remove elements from the vector, or
> reflect changes due to indirect modifications - SmallVectorImpl& would
> be the most suitable.
> On Fri, May 3, 2019 at 9:39 AM Russell Wallace via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > It is suggested in the documentation that if you would have declared a
> function parameter as SmallVector<Foo,N>&, it is better to instead declare
> it as SmallVectorImpl<Foo>&.
> >
> > This makes sense, but it seems to me that it is better still to declare
> it as ArrayRef<Foo>; a quick test suggests it compiles to the same (highly
> efficient) code, and adds a bit more flexibility in case e.g. you someday
> want to pass a std::vector.
> >
> > By that logic, there is never any reason to take a SmallVectorImpl,
> because ArrayRef is strictly better. Am I missing anything?
> > _______________________________________________
> > 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/20190503/0af3c325/attachment.html>

More information about the llvm-dev mailing list