I looked into making the move constructor (and move-assignment) for flex_vector noexcept. This is something people (at least myself) want to ensure exception safety. Generally you want you types to be nothrow move constructible.
It turns out to be not that trivial: it allocates nodes. This is similar to what the MSVC implementation of std::unordered_map does and it caused me a lot of pain in the past. At least the swap operation is de facto noexcept, but not marked as such.
I propose two solutions:
- do not allocate anything unless necessary. This would introduce some special cases, where
nullptr to head and tail node would indicate an empty flex_vector.
- This is similar to libstdc++ does for
std::unordered_map: store the end nodes within the object itself. This would require to replace the end-nodes with the new end-nodes during a move operation.
I prefer approach 1. Any ideas or opinions? Maybe there is a good reason to not have flex_vectors move constructor and assignment noexcept.
I looked into making the move constructor (and move-assignment) for
flex_vectornoexcept. This is something people (at least myself) want to ensure exception safety. Generally you want you types to be nothrow move constructible.It turns out to be not that trivial: it allocates nodes. This is similar to what the MSVC implementation of
std::unordered_mapdoes and it caused me a lot of pain in the past. At least theswapoperation is de facto noexcept, but not marked as such.I propose two solutions:
nullptrto head and tail node would indicate an empty flex_vector.std::unordered_map: store the end nodes within the object itself. This would require to replace the end-nodes with the new end-nodes during a move operation.I prefer approach 1. Any ideas or opinions? Maybe there is a good reason to not have flex_vectors move constructor and assignment noexcept.