Date: Sun, 1 Jun 2025 18:36:42 +0200
On 01.06.25 18:13, Maryam via Std-Proposals wrote:
> You are right that “major architectures” will not be an issue. But people assume portability when it comes to the C++ standard. The implication is that hardware-dependent functions will be left out unless extremely common. Some ISAs, mainly used in resource-constrained systems, have no support for and really don’t need anything beyond the basics.
>
> If I am building the compiler for such hardware, I don’t support functions that are irrelevant to the hardware’s use cases.
We already have a bunch of functions that not all hardware might support,
e.g. those in <bit>, which are marked as "all freestanding".
If a platform doesn't have a hardware instruction for integer divide,
the compiler would need to defer to a software implementation anyway,
in order to fully implement the core language.
> This is very common in embedded, where vendors might build their own compilers.
> What does that mean in practice? People can’t reuse code that many compilers don’t support.
Then those compilers are simply not conforming, if they don't offer all
the functions the C++ standard prescribes. Nothing to see here.
> A bigger standard (more functions, more uncommon features) ->
> Compilers will be more complex and expensive ->
> Less likely that a typical compiler will support the standard fully ->
> C++ standard will be less portable ->
> The standard won’t be a “standard”
That chain of reasoning applies to every single feature added to
the C++ standard, and it's good to judge every single feature along
those lines. However, with basic linear algebra support and senders/receivers,
we've added much larger features fairly recently, because we considered
them worthwwhile. So, the question is not "is it feasible", but the question
is "is it worth it".
> Today, most compilers don’t support C++17 and later. Many compilers and teams are totally fine sticking with C++11.
So? C++23 is the current release of C++, and implementations can choose
to conform or stop being relevant in a few years.
> We aren’t trying to build a legacy for ourselves but serve billions of users; we are trying to maintain an “ISO Standard.” By definition, it must be fundamental and general purpose (of course, of the highest quality). Otherwise, the feature can very well be a library and integrated only by those who need it. A good standard must be small; less is more. WG 14 is doing a great job leaving unnecessary features for library developers. However, if an open-source library becomes popular and successful with invaluable implementation experience, it will have a smoother path toward standardization.
>
> So why the same reason that would make WG 14 not want it in the standard not apply here?
WG14 and WG21 are distinct committees that each make independent decisions.
I don't think WG21 should tie their library decisions to WG14, and the
reverse is also not true. For example, WG14 standardized the <bit>
functions under slightly different names.
> This might not be a popular thing to say, but it is the reality: While Objective-C is a strict superset of C, C++ is a partial superset. C++ is not like those other aforementioned languages. The survival of C++ depends on C. Assume hypothetically that all system software ––which is written in C–– was magically rewritten in Rust. Outcome: Rust will replace C++.
>
> Academia doesn’t teach people how folks in the industry make pragmatic decisions. We choose a tech stack that best suits the purpose, fits the budget and saves time. For us, C++ makes sense because it is:
>
> A partial superset of C <- Interoperability, skillset and code reuse, etc.
> High-level OO <- Productivity.
>
> Otherwise, Rust and various high-level languages would do the job just fine. Without C, C++ will have no future in the industry. These two complement each other; they aren’t enemies or strangers.
Nobody said otherwise, but anyone can choose to present a proposal to either
C or C++, as they please.
Jens
> You are right that “major architectures” will not be an issue. But people assume portability when it comes to the C++ standard. The implication is that hardware-dependent functions will be left out unless extremely common. Some ISAs, mainly used in resource-constrained systems, have no support for and really don’t need anything beyond the basics.
>
> If I am building the compiler for such hardware, I don’t support functions that are irrelevant to the hardware’s use cases.
We already have a bunch of functions that not all hardware might support,
e.g. those in <bit>, which are marked as "all freestanding".
If a platform doesn't have a hardware instruction for integer divide,
the compiler would need to defer to a software implementation anyway,
in order to fully implement the core language.
> This is very common in embedded, where vendors might build their own compilers.
> What does that mean in practice? People can’t reuse code that many compilers don’t support.
Then those compilers are simply not conforming, if they don't offer all
the functions the C++ standard prescribes. Nothing to see here.
> A bigger standard (more functions, more uncommon features) ->
> Compilers will be more complex and expensive ->
> Less likely that a typical compiler will support the standard fully ->
> C++ standard will be less portable ->
> The standard won’t be a “standard”
That chain of reasoning applies to every single feature added to
the C++ standard, and it's good to judge every single feature along
those lines. However, with basic linear algebra support and senders/receivers,
we've added much larger features fairly recently, because we considered
them worthwwhile. So, the question is not "is it feasible", but the question
is "is it worth it".
> Today, most compilers don’t support C++17 and later. Many compilers and teams are totally fine sticking with C++11.
So? C++23 is the current release of C++, and implementations can choose
to conform or stop being relevant in a few years.
> We aren’t trying to build a legacy for ourselves but serve billions of users; we are trying to maintain an “ISO Standard.” By definition, it must be fundamental and general purpose (of course, of the highest quality). Otherwise, the feature can very well be a library and integrated only by those who need it. A good standard must be small; less is more. WG 14 is doing a great job leaving unnecessary features for library developers. However, if an open-source library becomes popular and successful with invaluable implementation experience, it will have a smoother path toward standardization.
>
> So why the same reason that would make WG 14 not want it in the standard not apply here?
WG14 and WG21 are distinct committees that each make independent decisions.
I don't think WG21 should tie their library decisions to WG14, and the
reverse is also not true. For example, WG14 standardized the <bit>
functions under slightly different names.
> This might not be a popular thing to say, but it is the reality: While Objective-C is a strict superset of C, C++ is a partial superset. C++ is not like those other aforementioned languages. The survival of C++ depends on C. Assume hypothetically that all system software ––which is written in C–– was magically rewritten in Rust. Outcome: Rust will replace C++.
>
> Academia doesn’t teach people how folks in the industry make pragmatic decisions. We choose a tech stack that best suits the purpose, fits the budget and saves time. For us, C++ makes sense because it is:
>
> A partial superset of C <- Interoperability, skillset and code reuse, etc.
> High-level OO <- Productivity.
>
> Otherwise, Rust and various high-level languages would do the job just fine. Without C, C++ will have no future in the industry. These two complement each other; they aren’t enemies or strangers.
Nobody said otherwise, but anyone can choose to present a proposal to either
C or C++, as they please.
Jens
Received on 2025-06-01 16:36:47