This CL focuses on addressing the remaining TODO items in the
`//rtc_base/bounded_inline_vector_impl.h` file, mainly involving the two
functions `void DefaultInitializeElements` and `void MoveElements`.
In the `void DefaultInitializeElements` function, the placement new usage is
adopted. When using placement new, manual construction operations on objects are
usually required, and a fair amount of logic needs to be written to ensure
correct object construction. In contrast, the
`std::uninitialized_default_construct_n()` function only requires passing in the
starting address of the memory and the number of objects to be constructed, and
it can automatically construct objects in batches.
In the `void MoveElements` function, the original implementation also uses the
placement new usage. When using placement new to move objects, manual handling
of the moving operation for each object is required, and usually, `std::move`
needs to be combined to achieve the object's move semantics. However, the
`std::uninitialized_move_n()` function can automatically complete the object
moving process just by passing in specific parameters.
To improve the code's simplicity, it is considered to use
`std::uninitialized_default_construct_n()` and `std::uninitialized_move_n()` to
replace the original two placement new usages.
Fixed: webrtc:392037564
Change-Id: If8edcd9ac8a4d85be0ce0a23f6433d7f91b39ad3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375182
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Ho Cheung <hocheung@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43831}
Selling point is that it never touches the heap. Intended use case is
cheaply returning a variable, bounded, and small number of things from
a function.
Specifically, there are situations where we'd like to return things like
ArrayView<ArrayView<float>>
where we currently have to allocate an array of ArrayView<float> for
the outer ArrayView to point to, which is a bother; however, although
the outer ArrayView is of variable size, that size is statically
guaranteed to not exceed some small constant. After this CL, we'll be
able to instead return
BoundedInlineVector<ArrayView<float>, kSmallConstant>
which is much more convenient. We already had the option of returning e.g.
std::vector<ArrayView<float>>
but that would bloat our binary with code to handle heap allocations
in places we'd rather be lean and mean.
https://godbolt.org/z/r-vcPj demonstrates that the overhead compared to
a raw C array + a size is ~zero.
Bug: webrtc:11391
Change-Id: Ifb6d937193052588be641aa62cc67ba0ec64ded6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168944
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30663}
