[llvm] 7193f72 - docs: Emphasize ArrayRef over SmallVectorImpl
Duncan P. N. Exon Smith via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 6 15:16:18 PDT 2020
Author: Duncan P. N. Exon Smith
Date: 2020-10-06T18:13:52-04:00
New Revision: 7193f727988360acb7037b42851f0a6fae29af9b
URL: https://github.com/llvm/llvm-project/commit/7193f727988360acb7037b42851f0a6fae29af9b
DIFF: https://github.com/llvm/llvm-project/commit/7193f727988360acb7037b42851f0a6fae29af9b.diff
LOG: docs: Emphasize ArrayRef over SmallVectorImpl
The section on SmallVector has a note about preferring SmallVectorImpl
for APIs but doesn't mention ArrayRef. Although ArrayRef is discussed
elsewhere, let's re-emphasize here.
Differential Revision: https://reviews.llvm.org/D49881
Added:
Modified:
llvm/docs/ProgrammersManual.rst
Removed:
################################################################################
diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst
index 8d028a64b65f..d9925d69d9f6 100644
--- a/llvm/docs/ProgrammersManual.rst
+++ b/llvm/docs/ProgrammersManual.rst
@@ -1541,30 +1541,43 @@ SmallVector has grown a few other minor advantages over std::vector, causing
.. note::
- Prefer to use ``SmallVectorImpl<T>`` as a parameter type.
+ Prefer to use ``ArrayRef<T>`` or ``SmallVectorImpl<T>`` as a parameter type.
- In APIs that don't care about the "small size" (most?), prefer to use
- the ``SmallVectorImpl<T>`` class, which is basically just the "vector
- header" (and methods) without the elements allocated after it. Note that
- ``SmallVector<T, N>`` inherits from ``SmallVectorImpl<T>`` so the
- conversion is implicit and costs nothing. E.g.
+ It's rarely appropriate to use ``SmallVector<T, N>`` as a parameter type.
+ If an API only reads from the vector, it should use :ref:`ArrayRef
+ <dss_arrayref>`. Even if an API updates the vector the "small size" is
+ unlikely to be relevant; such an API should use the ``SmallVectorImpl<T>``
+ class, which is the "vector header" (and methods) without the elements
+ allocated after it. Note that ``SmallVector<T, N>`` inherits from
+ ``SmallVectorImpl<T>`` so the conversion is implicit and costs nothing. E.g.
.. code-block:: c++
- // BAD: Clients cannot pass e.g. SmallVector<Foo, 4>.
+ // DISCOURAGED: Clients cannot pass e.g. raw arrays.
+ hardcodedContiguousStorage(const SmallVectorImpl<Foo> &In);
+ // ENCOURAGED: Clients can pass any contiguous storage of Foo.
+ allowsAnyContiguousStorage(ArrayRef<Foo> In);
+
+ void someFunc1() {
+ Foo Vec[] = { /* ... */ };
+ hardcodedContiguousStorage(Vec); // Error.
+ allowsAnyContiguousStorage(Vec); // Works.
+ }
+
+ // DISCOURAGED: Clients cannot pass e.g. SmallVector<Foo, 8>.
hardcodedSmallSize(SmallVector<Foo, 2> &Out);
- // GOOD: Clients can pass any SmallVector<Foo, N>.
+ // ENCOURAGED: Clients can pass any SmallVector<Foo, N>.
allowsAnySmallSize(SmallVectorImpl<Foo> &Out);
- void someFunc() {
+ void someFunc2() {
SmallVector<Foo, 8> Vec;
hardcodedSmallSize(Vec); // Error.
allowsAnySmallSize(Vec); // Works.
}
- Even though it has "``Impl``" in the name, this is so widely used that
- it really isn't "private to the implementation" anymore. A name like
- ``SmallVectorHeader`` would be more appropriate.
+ Even though it has "``Impl``" in the name, SmallVectorImpl is widely used
+ and is no longer "private to the implementation". A name like
+ ``SmallVectorHeader`` might be more appropriate.
.. _dss_vector:
More information about the llvm-commits
mailing list