3 ms·

> 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 oug

> 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

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.