On 5/12/22 01:27, Robert Ramey via Boost wrote:
On 4/19/22 7:42 AM, Vinnie Falco via Boost wrote:
My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users.
Very well put.
I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want,
Agreed
It's time to refactor the IOS committee.
a) redefine it's mission.
Such a committee should address issues of the core language only.
b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every.
Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well.
I assume you mean "ISO" committee, that is WG21? While I agree that the standard library defined by the C++ standard is insufficient for any more or less advanced programming (i.e. anything more complicated than simple "Hello World" style applications), and I personally consider Boost as the natural, almost mandatory extension of the standard library, oftentimes preferred over the latter, I disagree that the work on the standard library is done, or that it isn't needed. It's actually the opposite. There is a number of fundamental library components that are required for the core language (std::type_info, exceptions and their interactions with core language like dynamic_cast, std::initializer_list, etc.). There is a number of utility tools which are used ubiquitously (std::string(_view), containers, std::pair, std::tuple, threads and synchronization, type traits). There is support for basic IO - even if it isn't suitable for anything sophisticated like mapped files or sockets, having no IO at all would be clearly worse. There is a considerable portion of the standard library that implements compatibility with C. And so on. All these things form a baseline on which any C++ program can rely regardless of the language implementation. It is important to have that baseline as it sets the lowest bar of what can be implemented in pure C++ with no external dependencies, and without many of the tools I listed no useful program is possible. The fact that we are forced to use Boost or Qt or GTK or whatever other framework of libraries to implement any real world applications indicates that this bar is too low currently. That said, I do agree that the current approach to the standard library evolution is not scalable. I think, the standard library needs to become more modular, ironically, more similar to Boost (or where it aims to be). There needs to be a separate module for networking, for mapped IO, for parsing a-la Boost.Spirit, for JSON, XML and other widespread data formats, for GUI (non necessarily buttons and menus, but at least the ability to draw something on canvas), video and audio, for SIMD, for databases, for more containers and many many more. I think the committee is already moving in this direction, although they are still trying to cram everything in a single specification and market it under a single C++NN label. I think, this needs to change at some point so that every module is able to evolve at its own pace and in a separate specification that is addendum to the main C++ specification that describes core language and core standard library components. The main difference of this modular approach from the status quo is that there would be a formal specification for each module that every implementor would have to follow, and all users could rely on. Furthermore, there are multiple C++ language implementors, so there would be multiple implementations of each of these modules, arguably more optimized for the supported target platforms. Basically, you would have a portion of Boost or Qt shipped with every C++ compiler, with no extra dependencies. This is better in terms of accessibility, implementation quality and likely licensing. Because competition is always good.