Date: Sun, 1 Jun 2025 12:13:36 -0400
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. 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.
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”
Today, most compilers don’t support C++17 and later. Many compilers and teams are totally fine sticking with C++11.
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?
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.
> On May 31, 2025, at 12:49 AM, Jan Schultke <janschultke_at_[hidden]> wrote:
>
>> Why were the previous proposals abandoned?
>> Why do those same reasons not apply now?
>> What has changed?
>
> I'm pretty sure it's just author inactivity.
>
>> Architecture dependence. Yes, we can make it implementors’ problem,
>> but if many fail to provide efficient implementations ––since these are likely less common
>> compared to other hardware-dependent functions––then people won’t use them.
>> Perhaps this is one of the reasons why previous proposals were abandoned?
>
> This is a total non-issue. Every major architecture provides "native"
> division as a truncating division, which matches the semantics of the
> division operator in C++. Changing the rounding mode is then always
> adjusting the quotient by at most one. See
> https://isocpp.org/files/papers/P3724R0.html#implementation
>
> I don't even think you'd substantially benefit from intrinsics in any
> of these functions. They're as portable as they can get.
>
>> This is really a C thing.
>> There is nothing in this that C++ can do better than C.
>> If standardized in C, it will have a wider user base too,
>> and can be imported to C++ naturally.
>
> C is a separate language, not a ship vehicle for C++ features. You
> could just as well argue that it's a JavaScript or Rust thing.
>
> I'm not 100% sure that WG14 would want it anyway precisely because the
> implementation is too portable, and you could theoretically just copy
> and paste it into your project.
If I am building the compiler for such hardware, I don’t support functions that are irrelevant to the hardware’s use cases. 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.
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”
Today, most compilers don’t support C++17 and later. Many compilers and teams are totally fine sticking with C++11.
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?
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.
> On May 31, 2025, at 12:49 AM, Jan Schultke <janschultke_at_[hidden]> wrote:
>
>> Why were the previous proposals abandoned?
>> Why do those same reasons not apply now?
>> What has changed?
>
> I'm pretty sure it's just author inactivity.
>
>> Architecture dependence. Yes, we can make it implementors’ problem,
>> but if many fail to provide efficient implementations ––since these are likely less common
>> compared to other hardware-dependent functions––then people won’t use them.
>> Perhaps this is one of the reasons why previous proposals were abandoned?
>
> This is a total non-issue. Every major architecture provides "native"
> division as a truncating division, which matches the semantics of the
> division operator in C++. Changing the rounding mode is then always
> adjusting the quotient by at most one. See
> https://isocpp.org/files/papers/P3724R0.html#implementation
>
> I don't even think you'd substantially benefit from intrinsics in any
> of these functions. They're as portable as they can get.
>
>> This is really a C thing.
>> There is nothing in this that C++ can do better than C.
>> If standardized in C, it will have a wider user base too,
>> and can be imported to C++ naturally.
>
> C is a separate language, not a ship vehicle for C++ features. You
> could just as well argue that it's a JavaScript or Rust thing.
>
> I'm not 100% sure that WG14 would want it anyway precisely because the
> implementation is too portable, and you could theoretically just copy
> and paste it into your project.
Received on 2025-06-01 16:13:43