Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs

Subject: Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-23 07:05:23

On Thu, Jun 22, 2017 at 6:13 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> >> However I am thinking here in terms of WG21 standardisation,
> >> specifically SG14's work on a std::vector upgrade which doesn't have
> >> the really unfortunate unpredictable latency. The general idea is that
> >> a low latency std::vector would never expand its capacity
> >> automatically, instead it would return success + capacity approaching
> >> warning status. You then could schedule the construction of a new,
> >> bigger vector outside the hot path.
> >
> > I find this example as unconvincing as Lawrence's original one. For one,
> > vector functions that grow the size typically return void. So you could
> > just turn that into bool or an enum and you'd be done.
> >
> > For another, when you're in the hot path, the "capacity warning" status
> > is not actionable, so it's of little use. Instead, when you get out of
> > the hot path (or, better yet, before you get into it), you'd simply
> > check capacity(), see if it's yellow/red, and reserve. Or not even
> > check, just reserve( size() + <hot path max size requirement> ).
>
> All valid observations.
>
> 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.
>

If there is anything wrong with std::vector that isn't it.

If you want a container that is about as fast as vector when indexing but
can grow without reallocation, use deque. If you insist on the elements
being sequential in memory, reserve.

By the way, even if vectors didn't reallocate, the fact that the elements
must occupy sequential memory can become a problem on some platforms for
very large vectors, exacerbating heap fragmentation issues. Incidentally,
these tend to be the same platforms where the performance impact
on reallocations is most problematic.

At any rate, such issues are a consequence of language design choices
originating in C, and can not be alleviated by "fixing" std::vector.