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