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
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/
