Skip to content

Commit fb87f6d

Browse files
committed
Merge #19367: doc: Span pitfalls
fab57e2 doc: Mention Span in developer-notes.md (Pieter Wuille) 3502a60 doc: Document Span pitfalls (Pieter Wuille) Pull request description: This is an attempt to document pitfalls with the use of `Span`, following up on comments like bitcoin/bitcoin#18468 (comment) and bitcoin/bitcoin#18468 (comment) ACKs for top commit: laanwj: ACK fab57e2 Tree-SHA512: 8f6f277d6d88921852334853c2b7ced97e83d3222ce40c9fe12dfef508945f26269b90ae091439ebffddf03f939797cb28126b2387f77959069ef8909c25ab53
2 parents 19612ca + fab57e2 commit fb87f6d

File tree

2 files changed

+69
-0
lines changed

2 files changed

+69
-0
lines changed

doc/developer-notes.md

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -620,6 +620,19 @@ class A
620620
- *Rationale*: Easier to understand what is happening, thus easier to spot mistakes, even for those
621621
that are not language lawyers.
622622
623+
- Use `Span` as function argument when it can operate on any range-like container.
624+
625+
- *Rationale*: Compared to `Foo(const vector<int>&)` this avoids the need for a (potentially expensive)
626+
conversion to vector if the caller happens to have the input stored in another type of container.
627+
However, be aware of the pitfalls documented in [span.h](../src/span.h).
628+
629+
```cpp
630+
void Foo(Span<const int> data);
631+
632+
std::vector<int> vec{1,2,3};
633+
Foo(vec);
634+
```
635+
623636
- Prefer `enum class` (scoped enumerations) over `enum` (traditional enumerations) where possible.
624637

625638
- *Rationale*: Scoped enumerations avoid two potential pitfalls/problems with traditional C++ enumerations: implicit conversions to `int`, and name clashes due to enumerators being exported to the surrounding scope.

src/span.h

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,62 @@
2121
/** A Span is an object that can refer to a contiguous sequence of objects.
2222
*
2323
* It implements a subset of C++20's std::span.
24+
*
25+
* Things to be aware of when writing code that deals with Spans:
26+
*
27+
* - Similar to references themselves, Spans are subject to reference lifetime
28+
* issues. The user is responsible for making sure the objects pointed to by
29+
* a Span live as long as the Span is used. For example:
30+
*
31+
* std::vector<int> vec{1,2,3,4};
32+
* Span<int> sp(vec);
33+
* vec.push_back(5);
34+
* printf("%i\n", sp.front()); // UB!
35+
*
36+
* may exhibit undefined behavior, as increasing the size of a vector may
37+
* invalidate references.
38+
*
39+
* - One particular pitfall is that Spans can be constructed from temporaries,
40+
* but this is unsafe when the Span is stored in a variable, outliving the
41+
* temporary. For example, this will compile, but exhibits undefined behavior:
42+
*
43+
* Span<const int> sp(std::vector<int>{1, 2, 3});
44+
* printf("%i\n", sp.front()); // UB!
45+
*
46+
* The lifetime of the vector ends when the statement it is created in ends.
47+
* Thus the Span is left with a dangling reference, and using it is undefined.
48+
*
49+
* - Due to Span's automatic creation from range-like objects (arrays, and data
50+
* types that expose a data() and size() member function), functions that
51+
* accept a Span as input parameter can be called with any compatible
52+
* range-like object. For example, this works:
53+
*
54+
* void Foo(Span<const int> arg);
55+
*
56+
* Foo(std::vector<int>{1, 2, 3}); // Works
57+
*
58+
* This is very useful in cases where a function truly does not care about the
59+
* container, and only about having exactly a range of elements. However it
60+
* may also be surprising to see automatic conversions in this case.
61+
*
62+
* When a function accepts a Span with a mutable element type, it will not
63+
* accept temporaries; only variables or other references. For example:
64+
*
65+
* void FooMut(Span<int> arg);
66+
*
67+
* FooMut(std::vector<int>{1, 2, 3}); // Does not compile
68+
* std::vector<int> baz{1, 2, 3};
69+
* FooMut(baz); // Works
70+
*
71+
* This is similar to how functions that take (non-const) lvalue references
72+
* as input cannot accept temporaries. This does not work either:
73+
*
74+
* void FooVec(std::vector<int>& arg);
75+
* FooVec(std::vector<int>{1, 2, 3}); // Does not compile
76+
*
77+
* The idea is that if a function accepts a mutable reference, a meaningful
78+
* result will be present in that variable after the call. Passing a temporary
79+
* is useless in that context.
2480
*/
2581
template<typename C>
2682
class Span

0 commit comments

Comments
 (0)