Re: We have a new standard!

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.

The meaning of "cout << 0xFF << 2 << 1234;" is obviously a chain of
outputs - output 0xff, output 2, output 1234.  Regardless of the

I would expect all mathematical operations to work in EXACTLY the same way
in an output stream. Eg I expect the output to be 256 here:

std::cout << 255 + 1 << std::endl;

Yet here there is no maths involved:

std::cout << 255 << 1 << std::endl;

Thats perverse.

Its far clearer and you're just arguing for the sake of it. Extending your
logic why not just have one operator that does everything which varies with
context?
 

>
That's not "extending" my logic - it is simply failing to understand it.

I understand it perfectly. Your logic and reasoning are flawed and you're
trying to justify an unjustifiable design decision.

Having specific operators for specific tasks would actually make it easier
to learn and read in the same way having specific keywords for specific
tasks does. C++ problems due to arn't too many operators.
 

>
I agree that C++ does not have a problem of having too many operators -
but if there were a free-for-all to define operators, then I think that

Straw man. Thats not what I'm suggesting.

Umm, you do realise most compilers already do compile time analysis of
printf formatters otherwise they wouldn't be able to give warnings about
invalid types being passed.
 

>
Yes - they do /now/.  But they did not do so previously.  And the

So what? They could have done so in the past, its not rocket science.

compiler-specific warning checks on printf-style functions is a very
fragile solution, and depends on close matches between the compiler and

So what do you think the compiler will do with the new functions? Use unicorns
and moonbeams to check the format?