You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`ArrayVec` is a contiguous memory block where elements can be collected, threfore, a collection by definition and even though `core::collections` doesn't exist, it is the most natural module placement.
89
+
`ArrayVec` is a contiguous memory block where elements can be collected, therefore, a collection by definition and even though `core::collections` doesn't exist, it is the most natural module placement.
90
90
91
-
The API basically mimics most of the current `Vec` surface with some tweaks and additional methods to manage capacity. Notably, these additional methods are fallible versions of some well-known functions like `insert` that will return `Result` instead of panicking at run-time.
91
+
The API basically mimics most of the current `Vec` surface with some tweaks to manage capacity.
92
+
93
+
Notably, these tweaked methods are fallible versions of some well-known functions like `push` that will return `Result` instead of panicking at run-time. Since the upper capacity bound is known at compile-time, the compiler is likely going to remove most of the conditional bounding checking.
Self::CapacityOverflow=>"It is not possible to add more elements",
212
-
Self::NoElement=>"There are no elements in the vector",
213
-
};
214
-
write!(f, "{}", s)
215
-
}
216
189
}
217
190
```
218
191
219
-
Meaningless, unstable and deprecated methods like `reserve` or `drain_filter` weren't considered and in general, everything that includes or removes elements have a fallible version: `extend_from_cloneable_slice`, `extend_from_copyable_slice`, `pop`, `remove` and `swap_remove`.
192
+
Since it is known at compile-time the upper capacity bound, the compiler is likely going to remove the conditional bounding checking of the newly
220
193
221
-
A concrete implementation is available at https://github.com/c410-f3r/stack-based-vec.
194
+
Meaningless, unstable and deprecated methods like `reserve` or `drain_filter` weren't considered. A concrete implementation is available at https://github.com/c410-f3r/stack-based-vec.
222
195
223
196
# Drawbacks
224
197
[drawbacks]: #drawbacks
@@ -229,7 +202,7 @@ New and existing users are likely to find it difficult to differentiate the purp
229
202
230
203
### The current ecosystem is fine
231
204
232
-
Even with all the fragmentation, different types of memory usage is an overkill in certain situations. If someone wants to use stack memory in an embedded application, then it is just a matter of grabbing an appropriated crate.
205
+
`ArrayVec` might be an overkill in certain situations. If someone wants to use stack memory in a specific application, then it is just a matter of grabbing the appropriated crate.
0 commit comments