Path: 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 13:51:53 +0100
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <vl625a$3bj9b$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 02 Jan 2025 13:51:55 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0fcb1a720205bec4fee800415cc3ccab";
	logging-data="3525931"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187pqOeFffWTHXn9rc8iYC4BViEEfHz//4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:GpEdgNggj25nD6l8dJu5M5v6ygM=
Content-Language: en-GB
In-Reply-To: <vl5lvf$39de4$1@dont-email.me>

On 02/01/2025 10:23, Muttley@dastardlyhq.com wrote:
> On Thu, 2 Jan 2025 08:06:05 +0100
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 01/01/2025 17:33, Muttley@dastardlyhq.com wrote:
>>> On Wed, 1 Jan 2025 18:25:27 +0200
>>> Michael S <already5chosen@yahoo.com> gabbled:
>>>> Introduction of format() already showed that C++ committee is aware of
>>>> of the fact that "Stroustrup streams" are crap not only relatively to
>>>> format/printing facilities of more modern languages, but relatively
>>>> to what we have in C as well. std::print() proves that committee is not
>>>> only aware of the fact, but finally willing to consider fixes.
>>>
>>> Plus overloading << and >> was a cretinous decision. There was zero 
>>> reason
>>> he couldn't have created some new operators to avoid confusion, <<< 
>>> and >>>
>>> or <= , => for example where such combinations in C would never be legal
>>> syntax anyway.
>>>
>>
>> I don't actually agree - I think the choice of << and >> was not a bad 
>> one, though <= and => could have worked too.  Adding new operators 
>> just for the purpose of streams would have been overkill, IMHO.  The big 
> 
> 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.

> Even Bjarne must've thought at the time that 
> something like:
> 
> 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;").

> 
> would require brackets whereas
> 
> 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 
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.

Maybe there /are/ good reasons for preferring <= to <<.  But arguing 
about clarity in inherently unclear and unrealistic code is not going to 
show them.


According to "The Design and Evolution of C++", Unix redirection 
operators were a major inspiration for the choice of << and >>. 
Operator precedence and associativity were important too.  (<<= and >>= 
have the wrong binding.)

> 
>> alternative would have been to have a way to add new operators to the 
>> language.  That would have been a huge change to C++ - the language, the 
> 
> Why would it?
> 

It would be a significant change to the syntax and grammar of the 
language, complicating parsing, analysis and compilation.  And they 
would, presumably, be used - for good and for bad, with that distinction 
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.


>> IMHO the real mistake for iostreams for formatted output was making 
>> them modal - IO manipulators are a /terrible/ idea.  The type system 
>> and overloading should have been used instead, so that we would write :
>>
>>     cout << hex(x);
>>
>> instead of
>>
>>     cout << hex << x << dec;
> 
> Agreed.
> 
>> There are still plenty of other issues with the iostreams formatted 
>> output, but the choice of operator is the least of the problems.
> 
> Personally I think printf() should have been upgraded for C++ from the 
> start
> so you could use all the normal formatters but have new ones for object 
> output with a slightly different format that would achieve similar. eg:
> 
> int i = 123;
> const std::string s = "hello";
> printf("%d: %$o\n",i,s);
> 
> In this case %$o would mean output yourself as a C char*.
> 
> 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 
(unlike C "printf").  Format strings (for std::format and std::print) 
are parsed at compile-time, checking both the numbers of parameters, 
types, and format specifiers.  This means that they need a significantly 
different style of format specifiers than printf used - and the Python 
ones were probably as good as any other option because they solve the 
same problem.

Could this all have been done from the start of C++?  In theory, yes - 
in practice no.  std::format and std::print rely on various modern C++ 
features, such as compile-time evaluation of functions, and are 
dependent on optimising compilers to produce anything remotely 
efficient.  (This has become steadily more important - C++ code 
generation would usually be terrible if the compiler cannot inline small 
utility functions.)