Timeline for C++11 Custom Vector Implementation
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 26, 2021 at 12:29 | comment | added | Peter Cordes |
@MatthieuM.: Yeah, following the [stdatomic] tag on SO, I've seen the evidence of how limited the things you can do with it are, without hacks like writing a wrapper or derived class to add copy constructors that you don't intend to ever get used (which would solve the push_back problem too). Interesting point about other reasons, that makes sense.
|
|
| Sep 26, 2021 at 10:06 | comment | added | Matthieu M. |
@PeterCordes: The dirty truth about std::vector is that it's nigh impossible to use on non-movable, non-copyable types, no matter how hard pop_back tries. Any function which adds an element requires the ability to grow the storage and move/copy the elements, any function which erases an element requires the ability to move/copy the other elements to fill the gap. The real reason for pop_back not returning a value is due to its age: it was standardized prior to move semantics, and not returning simplifies exception handling.
|
|
| Sep 25, 2021 at 20:35 | comment | added | G. Sliepen |
@PeterCordes It should indeed be possible to do a template specialization, or with C++17 you can just have an auto return type and do if constexpr(can_move_or_copy<T>) return value; else return;. I'll just say that the STL approach avoids the whole issue, and matching STL API and semantics is usually a good thing. I would create an out-of-class pop_back_value() convenience function that works for any container that has pop_back() and back().
|
|
| Sep 25, 2021 at 20:01 | comment | added | Peter Cordes |
Since you mention the template param type, it might be interesting to specialize used_elements to just be an unsigned int with std::conditional< BUFFER_SIZE<= ...limits<unsigned>::max , unsigned, std::size_t >. That would save a bit of space on e.g. 64-bit systems for non-huge instances (only when alignof(T)<alignof(size_t) though, otherwise the class has padding). And reduces the alignment requirement of the container class in that case. (IDK if that's worth posting as a separate answer.)
|
|
| Sep 25, 2021 at 19:39 | comment | added | Peter Cordes |
I think @MatthieuM. meant rarity by fraction of actual containers in real code, not rarity by classes in real code. Yes, std::atomic is an example, but how many programs have a std::vector< std::atomic<int> >? There are definitely Stack Overflow Q&As about the error messages you get from trying to do that (anything that might reallocate won't compile), so some people may have gone ahead and used it in the limited ways that are possible. Or std::array< std::atomic<int> > is even more likely. But that's still a very small fraction of total uses of STL containers in C++ codebases.
|
|
| Sep 25, 2021 at 19:35 | comment | added | Peter Cordes |
Not being hyper-generic sounds appropriate for a custom container that nobody's proposing for a standard library. It's worth noting in a comment that this is something you'd need to change if you want to support that rare corner case, though. Can you have a template specialization for <T> that's copyable or movable to add a value-returning pop function? If you can find a name for it that isn't confusing, e.g. pop_back is used by std::vector to mean something else, so it's not a great choice. Maybe pop_back_value?
|
|
| Sep 25, 2021 at 12:28 | comment | added | Matthieu M. | We'll have to agree to disagree on that one, then, I am afraid. | |
| Sep 25, 2021 at 11:49 | comment | added | G. Sliepen |
@MatthieuM. They are not really really rare, std::mutex is an obvious one, std::atomic<> is another one. It is exactly because the STL containers handle even the weirdest usecases that they are so useful. If you just want something that works for your own project, sure, only implement what you need. But if you want to make something genericly useful, you should make sure it handles these usecases.
|
|
| Sep 25, 2021 at 11:36 | comment | added | Matthieu M. |
You are technically correct -- and this is likely why std::vector does so -- however the curse of "hyper-genericity" that hampers the standard library is best not emulated. Non-moveable objects are really rare. Really, really, rare. Constraining an interface to accommodate even the weirdest usecases at the cost of general ergonomics is a poor trade-off. Let the weirdest usecases call auto x = v.back(); v.erase(v.end()-1); and let the 99.9% of other use auto x = v.pop_back();.
|
|
| Sep 25, 2021 at 11:31 | comment | added | G. Sliepen | @MatthieuM. Sure, but then it would only work for types that are movable or copyable. By separating popping from accessing the element, the container will work for types that are neither. | |
| Sep 25, 2021 at 11:30 | comment | added | Matthieu M. |
I'd like to disagree with the pop_back advice. Having back() is good, but being able to pop is great. Do ensure it's a move, not a copy, though.
|
|
| Sep 24, 2021 at 16:15 | history | edited | G. Sliepen | CC BY-SA 4.0 |
added 531 characters in body
|
| Sep 24, 2021 at 13:55 | history | answered | G. Sliepen | CC BY-SA 4.0 |