Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121358 > unrolled thread

Re: We have a new standard!

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-01 18:25 +0200
    Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-01 16:33 +0000
      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-01 09:41 -0800
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 08:06 +0100
        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-02 09:23 +0000
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 13:51 +0100
            Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 14:07 +0000
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:54 +0100
                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 17:15 +0000
                  Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:58 -0800
                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:13 +0000
                      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:22 -0800
                        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:17 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:31 +0100
                            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 11:34 +0000
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 14:01 +0100
                                Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 15:49 +0000
                      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:42 -0800
                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-02 15:20 -0500
                  Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 13:43 +0100
                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 08:11 -0500
                      Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 16:33 +0200
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 10:50 -0500
                          Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 16:09 +0000
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:53 -0500
                              Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-03 17:10 +0000
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 12:14 -0500
                                  Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:13 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 18:17 +0100
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 13:58 -0500
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:39 +0100
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 09:56 -0500
                          Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 21:46 +0200
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 21:06 -0500
                              Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 18:32 -0800
                              Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-04 20:08 +0200
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 14:46 -0500
                                Re: We have a new standard! wij <wyniijj5@gmail.com> - 2025-01-05 07:14 +0800
                                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-06 08:38 +0000
                                  Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-07 08:40 -0500
                                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-07 14:04 +0000
                                      Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-08 14:52 -0500
                                        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-08 13:31 -0800
                                        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-09 08:39 +0000
                                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-07 21:32 -0500
                        Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:49 -0800
                      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 17:12 +0100
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:56 -0500
            Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 17:35 +0200
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:57 +0100
                Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 19:55 +0200
        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:40 -0800
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 09:42 +0100
      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:38 -0800
        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:09 +0000
          Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:19 -0800
            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:15 +0000
    Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-01 22:43 +0200
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 07:56 +0100
      Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-02 00:39 -0800
        Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 12:31 +0200
          Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 14:59 +0200
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 15:50 +0200
          Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-07 21:15 -0800
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-08 08:44 +0200
              Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-08 11:44 +0200
                Re: We have a new standard! James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-08 15:04 -0500
                Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 08:49 -0800
              Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 09:12 -0800
                Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-14 19:53 +0200
            Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-08 14:43 -0800
      Re: We have a new standard! scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:51 +0000
    Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 16:47 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#121358 — Re: We have a new standard!

On 27 Dec 2024 14:47:51 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>   According to one web site, C++23 (ISO/IEC 14882:2024) was released
>   October 19, 2024.
> 
>   (Sorry if it was mentioned here then, and I just did not notice!)
> 
>

I tried std::print both with gcc 14.2 and with clang 19.1.6 under
Windows/msys2 (ucrt variant of x86-64 toolsests). It works as
advertised. 
That is, an Windows 7 in default console windows it works as advertised
for as long as you had chosen a font that supports all languages that
you want to see. A default (Lucudia Console) was not good enough for my
mix of languages, but (less elegantly looking) Currier New did the job.
Supposedly, on newer versions of Windows it will work with default
fonts as well. 
For those who want to try it: new version of compiler is not enough,
you have to install new C++ libraries (in my case,
mingw-w64-ucrt-x86_64-libc++). And don't forget to specify -lstdc++exp
during linking.

Now to why, despite said above, I wouldn't use std::print() in its
current incarnation neither in production nor in hobby programs:
because compilation is too slow. ~4 seconds on the old home PC. I
didn't try on newer machines yet, but would be surprised if any of them
beats 2 seconds. Which is way above my threshold of inconvenience.


Nevertheless, it is a step in right direction. 
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.

[toc] | [next] | [standalone]

#121359

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.

[toc] | [prev] | [next] | [standalone]

#121361

On 01/01/2025 08:33 AM, 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.
>

A usual idea being . for concatenation, how about, adding ".=",
default definition a no-op or null-check, that it's close
to having "." for concatenation, ".=".

Being able to overload operators is considered one of
the coolest things about C++ and for figuring out the
arithmetizations and algebraizations and geometrizations
or what it actually makes sense to overload the operators
that they have the same meaning as arithmetic and algebra
or in geometry, has that "." is usual in formal methods
for concatenation while of course it's an accessor or
as it were in C++, dot, then about ".=" whether that
would be a grammar production as it were.

Since l.t. and g.t. are such great brackets as angle
brackets besides, it's because C has them for shift,
that they're arithmetic, why syntactically or lexically
as it may be, using angle brackets for inequalities also
has that in expressions they're as punctuation while
in templates which is so great they're parenthetical
or bracketing, grouping with respect to comma and so on.

Most people might not use usual C++ I/O yet, when the
inputs are like zillions of rows of line records then one
can imagine that it results expressive yet terse code.

[toc] | [prev] | [next] | [standalone]

#121365

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 
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 
tools, and the way we write code.  Maybe it would have been good, maybe 
bad, but certainly it would have been big.

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;


There are still plenty of other issues with the iostreams formatted 
output, but the choice of operator is the least of the problems.

[toc] | [prev] | [next] | [standalone]

#121367

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

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

would require brackets whereas

cout <= OxFF << 2 <= 1234;

is a lot clearer and doesn't.

>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?

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

[toc] | [prev] | [next] | [standalone]

#121369

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

[toc] | [prev] | [next] | [standalone]

#121372

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. Overloading << and >> was unnecessary and confusing.

>> 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?

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

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

>> 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? 

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

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

[toc] | [prev] | [next] | [standalone]

#121375

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.

[toc] | [prev] | [next] | [standalone]

#121377

On Thu, 2 Jan 2025 17:54:18 +0100
David Brown <david.brown@hesbynett.no> wibbled:
>On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>> 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.

Committees often don't come up with optimal solutions. Using the same operator
for 2 entirely different operations unrelated in either concept or function
when there was no need to was illogical and perverse.

>The meaning of "cout << 0xFF << 2 << 1234;" is obviously a chain of 
>outputs - output 0xff, output 2, output 1234.  Regardless of the 

I would expect all mathematical operations to work in EXACTLY the same way
in an output stream. Eg I expect the output to be 256 here:

std::cout << 255 + 1 << std::endl;

Yet here there is no maths involved:

std::cout << 255 << 1 << std::endl;

Thats perverse.

>> 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 understand it perfectly. Your logic and reasoning are flawed and you're
trying to justify an unjustifiable design decision.

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

Straw man. Thats not what I'm suggesting.

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

So what? They could have done so in the past, its not rocket science.

>compiler-specific warning checks on printf-style functions is a very 
>fragile solution, and depends on close matches between the compiler and 

So what do you think the compiler will do with the new functions? Use unicorns 
and moonbeams to check the format?

[toc] | [prev] | [next] | [standalone]

#121384

Muttley@DastardlyHQ.org writes:
> On Thu, 2 Jan 2025 17:54:18 +0100
> David Brown <david.brown@hesbynett.no> wibbled:
>>On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>>> 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.
>
> Committees often don't come up with optimal solutions. Using the same operator
> for 2 entirely different operations unrelated in either concept or function
> when there was no need to was illogical and perverse.

Like "*" for multiplication and pointer dereferencing?  Like "&" for
bitwise "and" and address-of?  Like "-" for negation and subtraction?

>>The meaning of "cout << 0xFF << 2 << 1234;" is obviously a chain of 
>>outputs - output 0xff, output 2, output 1234.  Regardless of the 
>
> I would expect all mathematical operations to work in EXACTLY the same way
> in an output stream.

I would expect << and >> to have their usual precedence whether
overloaded or not.

>                      Eg I expect the output to be 256 here:
>
> std::cout << 255 + 1 << std::endl;

Which it is.

> Yet here there is no maths involved:
>
> std::cout << 255 << 1 << std::endl;
>
> Thats perverse.

Apparently your expectation was incorrect.

I understand that the precedence of "<<" and ">>" can be slightly
confusing when they're used for I/O -- but it's fairly rare for
operators with lower precedence than the shift operators to be used in
I/O.  Sure, you can write:

    std::cout << n = 42 << "\n";

and it won't compile, but parentheses are an easy fix and a good idea
anyway.

How often has it really been a problem for you?

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121387

On Thu, 02 Jan 2025 13:58:34 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>Muttley@DastardlyHQ.org writes:
>> On Thu, 2 Jan 2025 17:54:18 +0100
>> David Brown <david.brown@hesbynett.no> wibbled:
>>>On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>>>> 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.
>>
>> Committees often don't come up with optimal solutions. Using the same
>operator
>> for 2 entirely different operations unrelated in either concept or function
>> when there was no need to was illogical and perverse.
>
>Like "*" for multiplication and pointer dereferencing?  Like "&" for
>bitwise "and" and address-of?  Like "-" for negation and subtraction?

As you well know they derived from C and couldn't be changed. However I don't
believe using "&" for references was the best choice but at least it sort of
makes sense in context.

>> I would expect all mathematical operations to work in EXACTLY the same way
>> in an output stream.
>
>I would expect << and >> to have their usual precedence whether
>overloaded or not.

You're missing the point.

>>                      Eg I expect the output to be 256 here:
>>
>> std::cout << 255 + 1 << std::endl;
>
>Which it is.

No shit.

>> std::cout << 255 << 1 << std::endl;
>>
>> Thats perverse.
>
>Apparently your expectation was incorrect.

Don't be obtuse for the sake of arguing.

>    std::cout << n = 42 << "\n";
>
>and it won't compile, but parentheses are an easy fix and a good idea
>anyway.
>
>How often has it really been a problem for you?

Given I do a lot of bit twiddling low level code, more than you might
expect. And its not a problem per se as it can be solved with brackets, I'm
simply saying it was a daft design decision to overload << and >> when Bjarne
could have easily created new operators at no cost. There was NO requirement
in this case to be compatible with C because streams were C++ specific
functionality.

[toc] | [prev] | [next] | [standalone]

#121401

Muttley@DastardlyHQ.org writes:
> On Thu, 02 Jan 2025 13:58:34 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>>Muttley@DastardlyHQ.org writes:
>>> On Thu, 2 Jan 2025 17:54:18 +0100
>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>>On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>>>>> 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.
>>>
>>> Committees often don't come up with optimal solutions. Using the
>>> same operator for 2 entirely different operations unrelated in
>>> either concept or function when there was no need to was illogical
>>> and perverse.
>>
>>Like "*" for multiplication and pointer dereferencing?  Like "&" for
>>bitwise "and" and address-of?  Like "-" for negation and subtraction?
>
> As you well know they derived from C and couldn't be changed. However I don't
> believe using "&" for references was the best choice but at least it sort of
> makes sense in context.
>
>>> I would expect all mathematical operations to work in EXACTLY the same way
>>> in an output stream.
>>
>>I would expect << and >> to have their usual precedence whether
>>overloaded or not.
>
> You're missing the point.

No, I get your point.  I just disagree.

>>>                      Eg I expect the output to be 256 here:
>>>
>>> std::cout << 255 + 1 << std::endl;
>>
>>Which it is.
>
> No shit.
>
>>> std::cout << 255 << 1 << std::endl;
>>>
>>> Thats perverse.
>>
>>Apparently your expectation was incorrect.
>
> Don't be obtuse for the sake of arguing.

You used the word "expect".  I think you meant that you *want* it to
behave in certain ways.  You know the existing rules, and you strongly
dislike them.

>>    std::cout << n = 42 << "\n";
>>
>>and it won't compile, but parentheses are an easy fix and a good idea
>>anyway.
>>
>>How often has it really been a problem for you?
>
> Given I do a lot of bit twiddling low level code, more than you might
> expect. And its not a problem per se as it can be solved with brackets, I'm
> simply saying it was a daft design decision to overload << and >> when Bjarne
> could have easily created new operators at no cost. There was NO requirement
> in this case to be compatible with C because streams were C++ specific
> functionality.

I think you overstate the problems introduced by overloading <<
and >>.  I accept that you dislike them, and I'm not going to change
your opinion.  I suggest that there's probably not much point in
discussing it further.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121409

On Fri, 03 Jan 2025 11:22:09 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>Muttley@DastardlyHQ.org writes:
>> Don't be obtuse for the sake of arguing.
>
>You used the word "expect".  I think you meant that you *want* it to
>behave in certain ways.  You know the existing rules, and you strongly
>dislike them.

What I would expect in a language is for mathematical operators to have the
same precendence with numeric types whether overloaded or not. This isn't the 
case with << and >>.

[toc] | [prev] | [next] | [standalone]

#121410

On 04/01/2025 11:17, Muttley@dastardlyhq.com wrote:
> On Fri, 03 Jan 2025 11:22:09 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>> Muttley@DastardlyHQ.org writes:
>>> Don't be obtuse for the sake of arguing.
>>
>> You used the word "expect".  I think you meant that you *want* it to
>> behave in certain ways.  You know the existing rules, and you strongly
>> dislike them.
> 
> What I would expect in a language is for mathematical operators to have the
> same precendence with numeric types whether overloaded or not. This isn't the
> case with << and >>.
> 

In C++, << and >> have the same precedence with all types - just like 
all the other operators.  The precedences are built into the grammar of 
the language.

Are you suggesting that C++ compilers should somehow have omniscient 
knowledge of user-defined types to know whether some class is a 
"numeric" type or some other kind of type which should have different 
precedences for different operators?  Do you think that would lead to a 
language that is clearer and easier to learn?

[toc] | [prev] | [next] | [standalone]

#121411

On Sat, 4 Jan 2025 12:31:33 +0100
David Brown <david.brown@hesbynett.no> gabbled:
>On 04/01/2025 11:17, Muttley@dastardlyhq.com wrote:
>> On Fri, 03 Jan 2025 11:22:09 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>>> Muttley@DastardlyHQ.org writes:
>>>> Don't be obtuse for the sake of arguing.
>>>
>>> You used the word "expect".  I think you meant that you *want* it to
>>> behave in certain ways.  You know the existing rules, and you strongly
>>> dislike them.
>> 
>> What I would expect in a language is for mathematical operators to have the
>> same precendence with numeric types whether overloaded or not. This isn't the
>
>> case with << and >>.
>> 
>
>In C++, << and >> have the same precedence with all types - just like 
>all the other operators.  The precedences are built into the grammar of 
>the language.
>
>Are you suggesting that C++ compilers should somehow have omniscient 
>knowledge of user-defined types to know whether some class is a 
>"numeric" type or some other kind of type which should have different 
>precedences for different operators?  Do you think that would lead to a 
>language that is clearer and easier to learn?

I'm tired of your straw men. If you can't discuss what I'm talking about 
then maybe stay silent.

[toc] | [prev] | [next] | [standalone]

#121413

On 04/01/2025 12:34, Muttley@dastardlyhq.com wrote:
> On Sat, 4 Jan 2025 12:31:33 +0100
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 04/01/2025 11:17, Muttley@dastardlyhq.com wrote:
>>> On Fri, 03 Jan 2025 11:22:09 -0800
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>>>> Muttley@DastardlyHQ.org writes:
>>>>> Don't be obtuse for the sake of arguing.
>>>>
>>>> You used the word "expect".  I think you meant that you *want* it to
>>>> behave in certain ways.  You know the existing rules, and you strongly
>>>> dislike them.
>>>
>>> What I would expect in a language is for mathematical operators to 
>>> have the
>>> same precendence with numeric types whether overloaded or not. This 
>>> isn't the
>>
>>> case with << and >>.
>>>
>>
>> In C++, << and >> have the same precedence with all types - just like 
>> all the other operators.  The precedences are built into the grammar 
>> of the language.
>>
>> Are you suggesting that C++ compilers should somehow have omniscient 
>> knowledge of user-defined types to know whether some class is a 
>> "numeric" type or some other kind of type which should have different 
>> precedences for different operators?  Do you think that would lead to 
>> a language that is clearer and easier to learn?
> 
> I'm tired of your straw men. If you can't discuss what I'm talking about 
> then maybe stay silent.
> 

Did you actually have any points other than "I want the code I write to 
work the way I want it to work, and sod the rest of the programming 
world" ?  If that's not it, then what did you mean when you incorrectly 
claimed that the precedence of << and >> in C++ is inconsistent?

(Note that I am quite happy to accept that you would have preferred a 
different operator here - that's personal preference, and I've no 
argument there.)

[toc] | [prev] | [next] | [standalone]

#121415

On Sat, 4 Jan 2025 14:01:00 +0100
David Brown <david.brown@hesbynett.no> gabbled:
>On 04/01/2025 12:34, Muttley@dastardlyhq.com wrote:
>> On Sat, 4 Jan 2025 12:31:33 +0100
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> On 04/01/2025 11:17, Muttley@dastardlyhq.com wrote:
>>>> On Fri, 03 Jan 2025 11:22:09 -0800
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>>>>> Muttley@DastardlyHQ.org writes:
>>>>>> Don't be obtuse for the sake of arguing.
>>>>>
>>>>> You used the word "expect".  I think you meant that you *want* it to
>>>>> behave in certain ways.  You know the existing rules, and you strongly
>>>>> dislike them.
>>>>
>>>> What I would expect in a language is for mathematical operators to 
>>>> have the
>>>> same precendence with numeric types whether overloaded or not. This 
>>>> isn't the
>>>
>>>> case with << and >>.
>>>>
>>>
>>> In C++, << and >> have the same precedence with all types - just like 
>>> all the other operators.  The precedences are built into the grammar 
>>> of the language.
>>>
>>> Are you suggesting that C++ compilers should somehow have omniscient 
>>> knowledge of user-defined types to know whether some class is a 
>>> "numeric" type or some other kind of type which should have different 
>>> precedences for different operators?  Do you think that would lead to 
>>> a language that is clearer and easier to learn?
>> 
>> I'm tired of your straw men. If you can't discuss what I'm talking about 
>> then maybe stay silent.
>> 
>
>Did you actually have any points other than "I want the code I write to 
>work the way I want it to work, and sod the rest of the programming 
>world" ?  If that's not it, then what did you mean when you incorrectly 
>claimed that the precedence of << and >> in C++ is inconsistent?

Keep those straw men coming. I have better things to do that argue the toss
any more.

[toc] | [prev] | [next] | [standalone]

#121403

On 01/03/2025 02:13 AM, Muttley@DastardlyHQ.org wrote:
> On Thu, 02 Jan 2025 13:58:34 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>> Muttley@DastardlyHQ.org writes:
>>> On Thu, 2 Jan 2025 17:54:18 +0100
>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>> On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>>>>> 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.
>>>
>>> Committees often don't come up with optimal solutions. Using the same
>> operator
>>> for 2 entirely different operations unrelated in either concept or function
>>> when there was no need to was illogical and perverse.
>>
>> Like "*" for multiplication and pointer dereferencing?  Like "&" for
>> bitwise "and" and address-of?  Like "-" for negation and subtraction?
>
> As you well know they derived from C and couldn't be changed. However I don't
> believe using "&" for references was the best choice but at least it sort of
> makes sense in context.
>
>>> I would expect all mathematical operations to work in EXACTLY the same way
>>> in an output stream.
>>
>> I would expect << and >> to have their usual precedence whether
>> overloaded or not.
>
> You're missing the point.
>
>>>                       Eg I expect the output to be 256 here:
>>>
>>> std::cout << 255 + 1 << std::endl;
>>
>> Which it is.
>
> No shit.
>
>>> std::cout << 255 << 1 << std::endl;
>>>
>>> Thats perverse.
>>
>> Apparently your expectation was incorrect.
>
> Don't be obtuse for the sake of arguing.
>
>>     std::cout << n = 42 << "\n";
>>
>> and it won't compile, but parentheses are an easy fix and a good idea
>> anyway.
>>
>> How often has it really been a problem for you?
>
> Given I do a lot of bit twiddling low level code, more than you might
> expect. And its not a problem per se as it can be solved with brackets, I'm
> simply saying it was a daft design decision to overload << and >> when Bjarne
> could have easily created new operators at no cost. There was NO requirement
> in this case to be compatible with C because streams were C++ specific
> functionality.
>
>

(I think the @-sign is kind of like a constant for null,
graphically, sort of like '~' itself and empty string,
with regards to constants and operators. Yet, it's
usually innocuous in lots of things like filenames,
that though I think of @-sign intead of like ""NUL"
the character, for void or null, and empty-string as
the tilde sort of has there's empty set up in math symbols,
yet, tilde and @ are on the keyboard.)

Some kind of idea that friend ostream functions would
make for a slightly different idiom that happened to
use the same otherwise output formatters, is a sort of
idea to make a sort of "slightly-less-featureful"
streams, as with regards to the idea put here about
for example "it's always UTF-8" or "don't bother sorting
except by the codepoint", with regards to locales,
and NLS strings, (non-language-strings?), and with
regards to "2024 world locale" that's sort of en_US,
and usually in UTC and where the euro has been in
ISO-8859 since ISO-8859-15, or along these lines,
here there's a consideration that there's no changing
all the friend ostream functions or as it were, while
still having an idiom that takes the formatters as
with regards to only having value expressions in the
output line, those being terms on the statement.

Then, about lazy evaluation, with the idea of
"pass this function pointer down to the emitter
before bothering to evaluate it in case it's discarded",
is about appenders pretty much, though as with regards
to going ahead and flushing out to the character stream
sort of whether there's a character stream or builder,
to have the same sort of output lines, that accept
either a character stream, a builder, or, a builder-builder.

Then it's sort of like these same functions or sources
could be compiled multiple times, hopefully without
changing how they're written, resulting a repurposing.


It meminds me of testing JavaScript or something,
and it was like, "just point the include dir at
a different lib and run it against the source-compatible
emulator and diagnostic device".

[toc] | [prev] | [next] | [standalone]

#121379

David Brown writes:

> On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>
>> 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.

And none of those "lots of people" recognized the major clusterfark that was  
dumped into C++98, in the form of throw specifiers, when they came about?

Let's see…: JDK 1.0 came out in 1996. I'm supposed to believe that not even  
one of those "lots of people" were aware of Java; were aware that in Java  
throw specifications were a part of, essentially, what C++ would call a  
method signature, and enforced by the compiler; and that if any code path  
fails to catch an exception it is ill-formed. And not /one/ of those people  
had the obvious "hey, that's what C++ should do, too" epiphany?

And when everyone was dragged, kicking and screaming, into admitting that  
throw specifications were a clusterfark, instead of fixing the mess it just  
got handwaived away, leaving behind just a token "noexcept" keyword, and a  
huge pile of code that now needs to be fixed, before it compiles again.

[toc] | [prev] | [next] | [standalone]

#121388

On 02/01/2025 21:20, Sam wrote:
> David Brown writes:
> 
>> On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
>>
>>> 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.
> 
> And none of those "lots of people" recognized the major clusterfark that 
> was dumped into C++98, in the form of throw specifiers, when they came 
> about?
> 
> Let's see…: JDK 1.0 came out in 1996. I'm supposed to believe that not 
> even one of those "lots of people" were aware of Java; were aware that 
> in Java throw specifications were a part of, essentially, what C++ would 
> call a method signature, and enforced by the compiler; and that if any 
> code path fails to catch an exception it is ill-formed. And not /one/ of 
> those people had the obvious "hey, that's what C++ should do, too" 
> epiphany?
> 

You can believe what you want - /I/ am not going to tell you what you 
are "supposed" to believe.  If you want to know the details of how C++ 
was designed and how it evolved, you can buy and read "The Design and 
Evolution of C++" covering up to about 1994.  For later information on 
why C++ is the way it is, Stroustrup published some more papers later. 
They are not hard to find: 
<https://en.wikipedia.org/wiki/Bjarne_Stroustrup#C++>

I am not a Java programmer, but I believe it has two kinds of exceptions 
- "checked exceptions" that are considered part of the "method 
signature", and "unchecked exceptions" that, like C++ exceptions, are 
/not/ part of the "method signature".  Java certainly seems to have 
viewed both types of exceptions as having their uses and advantages.

Much of Java - including its exceptions - are inspired by C++.  So long 
before Java was conceived, and certainly before checked exceptions were 
added and tried out in real-world code, C++ had already fixed on their 
style of exception that is not part of the function signature, and 
changing that would not have been at all easy.

> And when everyone was dragged, kicking and screaming, into admitting 
> that throw specifications were a clusterfark, instead of fixing the mess 
> it just got handwaived away, leaving behind just a token "noexcept" 
> keyword, and a huge pile of code that now needs to be fixed, before it 
> compiles again.
> 

I think it became fairly quickly apparent that "throw(...)" specifiers 
were not as useful in practice as had been hoped, and relatively few 
programmers used them except in the form "throw()".  So "throw(...)" was 
deprecated in C++11 and has been valid until C++17 (with compilers 
implementations being free to accept it as a non-standard extension far 
beyond that).  "throw()" was valid until C++20.  For most code, the fix 
needed to go from old-style "throw" specifiers to "noexcept" specifiers 
is to replace "throw()" with "noexcept()" - it can be done with a macro 
if you like.


(For my own use, I disable exceptions for C++.)

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web