Re: We have a new standard!

On Thu, 02 Jan 2025 13:58:34 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:

Muttley@DastardlyHQ.org writes:

On Thu, 2 Jan 2025 17:54:18 +0100
David Brown <david.brown@hesbynett.no> wibbled:

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.  Stroustrup was the main
language designer, but he was far from alone.

>
Committees often don't come up with optimal solutions. Using the same

operator

for 2 entirely different operations unrelated in either concept or function
when there was no need to was illogical and perverse.

>
Like "*" for multiplication and pointer dereferencing?  Like "&" for
bitwise "and" and address-of?  Like "-" for negation and subtraction?

As you well know they derived from C and couldn't be changed. However I don't
believe using "&" for references was the best choice but at least it sort of
makes sense in context.

I would expect all mathematical operations to work in EXACTLY the same way
in an output stream.

>
I would expect << and >> to have their usual precedence whether
overloaded or not.

You're missing the point.

                     Eg I expect the output to be 256 here:
>
std::cout << 255 + 1 << std::endl;

>
Which it is.

No shit.

std::cout << 255 << 1 << std::endl;
>
Thats perverse.

>
Apparently your expectation was incorrect.

Don't be obtuse for the sake of arguing.

   std::cout << n = 42 << "\n";
>
and it won't compile, but parentheses are an easy fix and a good idea
anyway.
>
How often has it really been a problem for you?

Given I do a lot of bit twiddling low level code, more than you might
expect. And its not a problem per se as it can be solved with brackets, I'm
simply saying it was a daft design decision to overload << and >> when Bjarne
could have easily created new operators at no cost. There was NO requirement
in this case to be compatible with C because streams were C++ specific
functionality.