Re: We have a new standard!

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

On Thu, 2 Jan 2025 13:51:53 +0100
David Brown <david.brown@hesbynett.no> wibbled:

On 02/01/2025 10:23, Muttley@dastardlyhq.com wrote:

Now maybe, but when the language was new I don't see the problem in
creating new
operators specifically for I/O. After all, he had to create new keywords so
why not operators?

>
C++ added "::", ".*" and "->*" early on, and C++20 added <=>.  (There
are also some new non-punctuation operators - like "new".)  Adding new
operators is certainly something that was done, but not done lightly.

 When the language is first created thats irrelevant. You add what you need
to add.

Agreed.

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.
Over the decades, C++ programmers have had plenty of complaints about the iostreams library.  While it is true that some people complain about the operators used, I don't believe it is the main complaint.

 

cout << 0xFF << 2 << 1234;

>
That doesn't require brackets (unless you are a fan of smart-arse
obfuscated code, and really wanted "cout << (0xff << 2) << 1234;").

 So adding brackets to differential shift from stream I/O is obfuscating is it?

The meaning of "cout << 0xFF << 2 << 1234;" is obviously a chain of outputs - output 0xff, output 2, output 1234.  Regardless of the precedences of operators or what operators are used, the only reason to write code that tries to use a chain of operators for something other than the obvious meaning is to try to look smart.
So "cout << 0xFF << 2 << 1234;" does not require brackets - it does what it appears to do.
If you had intended that the bit "0xff << 2" was to be evaluated as a shift, then you /do/ need parenthesis.  And unless you were trying (and failing) to look smart, you would use them even if the output used "<=" - or "<<<", or a dedicated new Unicode symbol like "⬱".

 

cout <= OxFF << 2 <= 1234;
>
is a lot clearer and doesn't.

>
It is not a lot clearer - it is no clearer at all.  If someone wrote

 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 didn't suggest that "cout << 0xFF << 2 << 1234;" was clearer than "cout <= 0xFF << 2 <= 1234;" if you wanted the shift operation - I said they are /both/ unclear.
Clarity is, of course, a matter of opinion - and your opinions on code clarity may differ from mine.  But please try to understand what I write.

that (in a parallel universe where <= was used for output streams), I'd
ask two questions.  First, is it a typo and the programmer meant to use
"<=" instead of "<<" ?  Secondly, I'd wonder what the *beep* the
programmer had intended at all, typo or not.

 Now you're trolling.
 

No.
Can you give any kind of realistic situation where you'd want to write code like this?  No, neither can I.  When someone writes code that has no clear purpose, the natural think is to question it.

According to "The Design and Evolution of C++", Unix redirection
operators were a major inspiration for the choice of << and >>.

 Perhaps they shouldn't have been. Perl munged shell and C style syntax and
look what a mess that turned out to be.
 

You wondered about the reasoning for the choices, I told you the reasoning.

Why would it?
>

>
It would be a significant change to the syntax and grammar of the
language, complicating parsing, analysis and compilation.  And they

 Huh? How would it make parsing MORE complicated? Have you ever written a
parser?

I haven't written a C++ parser.  But I believe (because I naïvely belief some things I have read on the internet without checking them) that it is impossible to make a parser for Raku (né Perl) that can parse all correct Perl code - and that key to this is the fact that you can define your own operators in Perl.
(Adding specific fixed operators would be a different matter.)

 

being very subjective.  You have said before (and not without reason)
that C++ can be hard to learn.  A plethora of new operators would not help.

 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 /would/ become a problem.  A few more might be okay, but not too many - and I really don't think input and output needs dedicated operators.

Presumably this is what the new print() and println() functions will do
except they seem to be using python style formatters for [reasons].
>

>
A key point is that the format string should never have to have
information about the type of the operands - thus it is type-safe

 It wouldn't need to. A particular formatter could just call some default
object output method just like streams do.
 

Could this all have been done from the start of C++?  In theory, yes -

 Thats when I'm refering to.
 

in practice no.  std::format and std::print rely on various modern C++
features, such as compile-time evaluation of functions, and are

 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 compiler-specific warning checks on printf-style functions is a very fragile solution, and depends on close matches between the compiler and the printf implementation.  It is not extendable to different types.