7 ms·

> Examples include exceptions as the one true error mechanism, and the use of implicit allocation. -fno-exceptions is very widely used and non-throwing variant

> Examples include exceptions as the one true error mechanism, and the use of implicit allocation. -fno-exceptions is very widely used and non-throwing variants of basically everything exist as a result. That's not a reason to avoid C++ in the kernel as a result. Especially with how heavily Linux already relies on GCC C extensions, there's obviously no hangups on being "strictly standard compliant." Not have exceptions ever been C++'s "one true error" mechanism ever. For example see iostream: https://www.cplusplus.com/reference/ios/ios/rdstate/ https://www.cplusplus.com/reference/ios/ios/rdstate/ C++ is not, and never has been, anywhere near that dogmatic. As for the rest of your points, you seem to be arguing Rust is better than C++. But that's not really relevant to why C++ was rejected before Rust even existed. I do think Rust is even better than C++, but I also think C++ is a huge improvement over C, especially for large codebases.

tialaramex 5y ago
It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. However whereas you can write -fno-exceptions and get a C++ with this core language feature excised, you can't do the same for implicit allocation. In contrast the Rust for Linux team have worked hard to produce a Rust for Linux environment that doesn't panic!() and has no implicit allocation, since these are red lines for Linus.
- kllrnohj 5y ago
  > It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. You're still trying to force C++ to be dogmatic. It never has been. It's always tried to be accommodating to all types of usages. It's always been multiparadigm. 'new' wasn't even defined to throw std::bad_alloc until C++98, which also introduced 'std::nothrow_t' to have it return null instead. > you can't do the same for implicit allocation Just like with exceptions this really isn't true, either. There's no implicit allocations in the core language, only in the STL. Saying that the "new" operator does implicit allocation is like saying "malloc" does implicit allocation. Regardless, placement new has always existed, and the non-placement 'new' operator has always been overridable. And all of the STL is optional & replaceable.
  - tialaramex 5y ago
    Being freely able to do X or not do X is "multiparadigm". But being told you must choose to either do X, or not do X, and either way obviously you lose access to all the software that expects the opposite, also by the way there are several more choices like this to make - is not "multiparadigm" it's schismatic. C++ has become lots of little silos of people using dialects that are in practice mutually unintelligible with other C++ dialects. Hence as I said the concern of the committee about this problem. What's the purpose of a "standard" which doesn't standardise anything? But to be sure, Linus could create yet another silo. And for implicit allocation, like I said, Rust for Linux did the work. C++ practitioners didn't. Linus isn't going to take something that doesn't exist just because its fans say if it did exist it would be suitable.
  - mlindner 5y ago
    There's no equivalent of Rust's core library that's in C++ though. So if you don't use the C++ STL you need to rebuild an entire library for all basic types. You also can't declare that your library doesn't need the STL.

tialaramex 5y ago

It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. However whereas you can write -fno-exceptions and get a C++ with this core language feature excised, you can't do the same for implicit allocation. In contrast the Rust for Linux team have worked hard to produce a Rust for Linux environment that doesn't panic!() and has no implicit allocation, since these are red lines for Linus.

kllrnohj 5y ago
> It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. You're still trying to force C++ to be dogmatic. It never has been. It's always tried to be accommodating to all types of usages. It's always been multiparadigm. 'new' wasn't even defined to throw std::bad_alloc until C++98, which also introduced 'std::nothrow_t' to have it return null instead. > you can't do the same for implicit allocation Just like with exceptions this really isn't true, either. There's no implicit allocations in the core language, only in the STL. Saying that the "new" operator does implicit allocation is like saying "malloc" does implicit allocation. Regardless, placement new has always existed, and the non-placement 'new' operator has always been overridable. And all of the STL is optional & replaceable.
- tialaramex 5y ago
  Being freely able to do X or not do X is "multiparadigm". But being told you must choose to either do X, or not do X, and either way obviously you lose access to all the software that expects the opposite, also by the way there are several more choices like this to make - is not "multiparadigm" it's schismatic. C++ has become lots of little silos of people using dialects that are in practice mutually unintelligible with other C++ dialects. Hence as I said the concern of the committee about this problem. What's the purpose of a "standard" which doesn't standardise anything? But to be sure, Linus could create yet another silo. And for implicit allocation, like I said, Rust for Linux did the work. C++ practitioners didn't. Linus isn't going to take something that doesn't exist just because its fans say if it did exist it would be suitable.
- mlindner 5y ago
  There's no equivalent of Rust's core library that's in C++ though. So if you don't use the C++ STL you need to rebuild an entire library for all basic types. You also can't declare that your library doesn't need the STL.