From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-05-23 16:21:28
On 2020-05-23 19:15, degski via Boost wrote:
> On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
>> Next, I disagree with the idea that a library could be "not allowed to
>> progress". Why block further improvements and extensions? Take
>> Boost.Atomic or Boost.FileSystem, for example. These libraries are not
>> equivalent to the standard counterparts, and offer extensions that are
>> useful in practice and cannot be efficiently implemented "on top" of the
>> standard components. What would be the point of a Boost.Atomic v2 if it
>> had to reimplement Boost.Atomic? We are spreading our time thin as it is
> The progression could be signified by another 'insertion mode' : increases
> begin(*X*) and executes end(*X*) = begin (*X*) +1.
I'm not sure what you mean here.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk