Re: We have a new standard!

On 02/01/2025 21:20, Sam wrote:

David Brown writes:
 

On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>

Overloading << and >> was unnecessary and confusing.

>
Disagreed.  I really don't think it was problematic.  Nor did any of the /many/ people who were involved in the design of C++.  Remember, the language and library has always been discussed, prototyped, and tested by lots of people before being released.

 And none of those "lots of people" recognized the major clusterfark that was dumped into C++98, in the form of throw specifiers, when they came about?
 Let's see…: JDK 1.0 came out in 1996. I'm supposed to believe that not even one of those "lots of people" were aware of Java; were aware that in Java throw specifications were a part of, essentially, what C++ would call a method signature, and enforced by the compiler; and that if any code path fails to catch an exception it is ill-formed. And not /one/ of those people had the obvious "hey, that's what C++ should do, too" epiphany?
 

You can believe what you want - /I/ am not going to tell you what you are "supposed" to believe.  If you want to know the details of how C++ was designed and how it evolved, you can buy and read "The Design and Evolution of C++" covering up to about 1994.  For later information on why C++ is the way it is, Stroustrup published some more papers later. They are not hard to find: <https://en.wikipedia.org/wiki/Bjarne_Stroustrup#C++>
I am not a Java programmer, but I believe it has two kinds of exceptions - "checked exceptions" that are considered part of the "method signature", and "unchecked exceptions" that, like C++ exceptions, are /not/ part of the "method signature".  Java certainly seems to have viewed both types of exceptions as having their uses and advantages.
Much of Java - including its exceptions - are inspired by C++.  So long before Java was conceived, and certainly before checked exceptions were added and tried out in real-world code, C++ had already fixed on their style of exception that is not part of the function signature, and changing that would not have been at all easy.

And when everyone was dragged, kicking and screaming, into admitting that throw specifications were a clusterfark, instead of fixing the mess it just got handwaived away, leaving behind just a token "noexcept" keyword, and a huge pile of code that now needs to be fixed, before it compiles again.
 

I think it became fairly quickly apparent that "throw(...)" specifiers were not as useful in practice as had been hoped, and relatively few programmers used them except in the form "throw()".  So "throw(...)" was deprecated in C++11 and has been valid until C++17 (with compilers implementations being free to accept it as a non-standard extension far beyond that).  "throw()" was valid until C++20.  For most code, the fix needed to go from old-style "throw" specifiers to "noexcept" specifiers is to replace "throw()" with "noexcept()" - it can be done with a macro if you like.
(For my own use, I disable exceptions for C++.)