Re: We have a new standard!

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.)