Re: Future of C++ and Boost

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-05-12 10:04:17

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.