Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-22 18:26:41

On 10/22/18 10:13 AM, Mike Dev via Boost wrote:

> What I do say however is that
> 1) having such a widely used implementation doesn't necessarily
>     reduce the amount of work the committee has to do in order to standardize:
>     Just have a look at the things from boost that got merged into the
>     standard (or where the committee is currently trying to merge them).
> 2) in times where everyone can easily publish their library on github on the
>     one hand and projects try to actively shed or avoid their dependency on
>     boost, having your library distributed as part of boost is certainly not
>     the only realistic way to get lots of usage feedback.
>     Ranges-v3 in particular became quite well-known and popular in the c++
>     community and I believe the main hurdle to its wide adoption was the
>     inability of MSVC to compile it - not that it wasn't part of Boost.
> 
> Again, I absolutely don't want to deny the value having a library going
> through boost prior to standardization. I'm just not convinced, that it
> would have helped the standardization process if ranges where developed
> as part of boost.
> 
> One general problems I see with standardizing existing practice btw:
> 
> A new library designed for use in production rarely gets written against
> the latest version of the c++ standard. Once it is written it takes quite
> some time until it gets adoped widely and even longer until it really
> becomes established practice.
> 
> So at the time where you start to work on standardization, the library
> is designed against a language that is probably 2-4 Standard revisions
> older than the one in which it will gets standardized. Depending on how
> much the language changed in between, and how much the library has evolved
> in the meantime you need to spend at least some effort (and sometimes
> considerable effort) to bring the design in line with modern language
> principles (Use std::chrono duration instead of ints, using string_view,

I'm arguing that the C++ standardization process is not useful for most 
C++ libraries.  The committee can't handle it.  This is pretty much a 
demonstrable fact as far as I'm concerned.  (I realize that people will 
disagree with this premise).  So this leaves a vacuum which 
organizations such a Boost can/should fill.

>    .
> Interesting point to think about: If you look at how standardization of
> communication protocols work (e.g. USB, Wifi PCI), they don't standardize
> established practice at all.

True, but their not standardizing any practice.  They don't approve code 
or APIS etc.  The leave that to someone else. They stick to the 
legitimate goals of standardization.

I believe that one of the original goals is to "standardize existing 
practice" and perhaps they shouldn't do that.  One thing that they do 
which no one else can do is specify language syntax and semantics. 
Expanding too far beyond this essential function can compromise the 
successful accomplishment of that very function.

Robert Ramey

> 
> 
> Mike
> 
>>
>> Robert Ramey
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>