Yet SG14 likes anything which relocates latency unpredictable things (exception throws, malloc, etc) to the caller. It's certainly how I'd have personally designed the STL originally. std::vector's latency insensitive design has always irritated me, and I still hope - without much basis - that any STL v2 will fix that.
I'm minded to try and deliver SG14 a vocabulary type which can help with that so they can propose it for standardisation.
Do you have in mind some outline of how this SG14-friendly, status-based, vector would look like? A few signatures are fine, no need to list the whole synopsis, although it's not that much.
Ah, that's not my field. I've just been monitoring the work of others. And do remember I'm not on SG14, I can't afford to attend their meetings, same as WG21 meetings. Most, but not all, of their work can be found at https://github.com/WG21-SG14. I can tell you however what I'd personally prefer, though be aware the below is off the top of my head and not thought through. Personally speaking, I'd prefer all STL v2 containers to be exclusively made up of composed views of fixed-at-construction capacity vectors and fixed-at-compile-time arrays. So you might create: std2::vector<int> a(3); // not three items, but capacity for three items a.push_back(1); // returns result<size_t, std::error_code> a.push_back(1); // returns success, capacity() - size() = 1 a.push_back(1); // returns success, capacity() - size() = 0 a.push_back(1); // returns failure, std::errc::not_enough_memory std2::vector<int> b(3); b.push_back(2); // returns success, capacity() - size() = 2 std2::span c(a, b); // compose c.size() == 4 c.push_back(2); // returns success, capacity() - size() = 1 c.size() == 5 c[0] == 1 c[3] == 2 c[4] == 2 std2::vector d(std::move(c)); // move contents into new storage And you'd keep going with the composing views up into associative maps etc, always being in direct manual control of any memory allocation at all times. std2::vector and std::array are the primitive containers, all other STL v2 containers are built on top in layers with reusable and generic views and spans. So you wouldn't really have an unordered_map container any more, you'd have a std2::mapping_view from a std::vector2 for the hash table onto a set of mapped items. You manually control buckets expansaion. That's the sort of design I'd personally prefer for STL v2 containers (remember no one is proposing to retire STL v1 containers, your std::vector<T> remains exactly as now). I appreciate it's not quite the Ranges TS and that's where things will actually end up at, but it's still very possible that SG14 will design their own low latency STL which doesn't repeat the latency unpredictability of the current STL or a Ranges TS based STL. We'll see. You probably have noted the lack of use of any positive status in any of the above. That's because the above is my personal preference, I'd personally speaking only see a wise use for positive status in insert operations on associative maps where a positive status indicates if a new key was inserted or if an existing value was replaced. But others have different opinions on all that, and as I mentioned my personal preference for STL v2 just described is not well thought through, so I defer to those who've done a lot more work on that. And they appear to want positive status more than I would personally see good reason for. Why I am not sure, because I don't know what they have planned for it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/