Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <20250101182527.00004b2f@yahoo.com> 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: Bytes: 6462 On 02/01/2025 10:23, Muttley@dastardlyhq.com wrote: > On Thu, 2 Jan 2025 08:06:05 +0100 > David Brown gabbled: >> On 01/01/2025 17:33, Muttley@dastardlyhq.com wrote: >>> On Wed, 1 Jan 2025 18:25:27 +0200 >>> Michael S 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.)