Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Thu, 2 Jan 2025 17:54:18 +0100
Organization: A noiseless patient Spider
Lines: 156
Message-ID: <vl6gbr$3e4rd$1@dont-email.me>
References: <C++-20241227154547@ram.dialup.fu-berlin.de>
 <20250101182527.00004b2f@yahoo.com> <vl3qpk$2rr3n$1@dont-email.me>
 <vl5dst$37mo5$2@dont-email.me> <vl5lvf$39de4$1@dont-email.me>
 <vl625a$3bj9b$1@dont-email.me> <vl66j6$3cbce$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 02 Jan 2025 17:54:22 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0fcb1a720205bec4fee800415cc3ccab";
	logging-data="3609453"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18V7sJndS1VkjZYaJgpkloyb6RL4mllyeM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:JDFF+KOFdS6wiOLKMPF4jJIcemg=
Content-Language: en-GB
In-Reply-To: <vl66j6$3cbce$1@dont-email.me>
Bytes: 7680

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.