Date: Sun, 24 Sep 2023 16:40:03 -0700
On Sunday, 24 September 2023 15:14:34 PDT Ville Voutilainen wrote:
> What Chris seems to be suggesting is that what's in the standard
> should've been less coupled and lower-level,
> so that you can polyfill your own stuff in the case of a buggy stdlib.
> That has its own downsides, so this
> is really a "water under the bridge, fix those libraries, or have them
> fixed".
That's not a job I wish on anyone.
I completely sympathise with people wanting to move their C++ codebases
forward without having to depend on buggy and old libraries. But the days of
Standard Libraries decoupled from compilers are 20 years behind us. If you're
unable to upgrade the Standard Library, you're unable to upgrade the compiler
itself and then you're probably out of luck using the new C++ Core Language
features in the first place.
It's true that the implementations deliver the C++ Standard Libraries features
more slowly than the Core Language ones (rationale for why is irrelevant).
That's the reason why in Qt we require the C++17 Core Language, but only C++11
Standard Library, which was a sensible decision in the 6.0 launch a few years
ago.
But this is not the basis of long-term proposals. This only works so long as
you're able to get a sufficiently recent compiler, but not so recent that you
wouldn't need the workaround in the first place. This is a snapshot in time,
like the Qt 6.0 requirements list, not something that you'd base the C++
Standard on.
The C++ Standard has to design a language that is long-term useful,
maintainable, teachable; that produces more readable and less error-prone
code. THIS is the message by the responders in this thread.
PS: don't raise the argument of RHEL/CentOS/Rocky's devtoolset compilers,
which upgrade the compiler without updating the library... because they don't.
They upgrade the Standard Library too. They just do it in a clever way such
that all new, non-inline symbols from the updated libstdc++ are in a *static*
library that gets statically linked into your application, instead of in the
system shared library. If you're using another vendor and they don't do this,
you can deploy it yourself because GCC+libstdc++ are open source.
> What Chris seems to be suggesting is that what's in the standard
> should've been less coupled and lower-level,
> so that you can polyfill your own stuff in the case of a buggy stdlib.
> That has its own downsides, so this
> is really a "water under the bridge, fix those libraries, or have them
> fixed".
That's not a job I wish on anyone.
I completely sympathise with people wanting to move their C++ codebases
forward without having to depend on buggy and old libraries. But the days of
Standard Libraries decoupled from compilers are 20 years behind us. If you're
unable to upgrade the Standard Library, you're unable to upgrade the compiler
itself and then you're probably out of luck using the new C++ Core Language
features in the first place.
It's true that the implementations deliver the C++ Standard Libraries features
more slowly than the Core Language ones (rationale for why is irrelevant).
That's the reason why in Qt we require the C++17 Core Language, but only C++11
Standard Library, which was a sensible decision in the 6.0 launch a few years
ago.
But this is not the basis of long-term proposals. This only works so long as
you're able to get a sufficiently recent compiler, but not so recent that you
wouldn't need the workaround in the first place. This is a snapshot in time,
like the Qt 6.0 requirements list, not something that you'd base the C++
Standard on.
The C++ Standard has to design a language that is long-term useful,
maintainable, teachable; that produces more readable and less error-prone
code. THIS is the message by the responders in this thread.
PS: don't raise the argument of RHEL/CentOS/Rocky's devtoolset compilers,
which upgrade the compiler without updating the library... because they don't.
They upgrade the Standard Library too. They just do it in a clever way such
that all new, non-inline symbols from the updated libstdc++ are in a *static*
library that gets statically linked into your application, instead of in the
system shared library. If you're using another vendor and they don't do this,
you can deploy it yourself because GCC+libstdc++ are open source.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-09-24 23:40:05