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!)
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!)
Stefan Ram writes:
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!)
Hip-hip-hooray! Finally, finally they addressed the long-standing criticism >of C++ being too trivial and too simple, and a kids' language. At last, >there's some meat on those bones. Watch out, Java! There's a new boss in >town. Real programming languages' specifications are measured in pounds,
and not a page count.
On Fri, 27 Dec 2024 21:51:10 -0500
Sam <[email protected]> gabbled:
Stefan Ram writes:
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!)
Hip-hip-hooray! Finally, finally they addressed the long-standing
criticism of C++ being too trivial and too simple, and a kids'
language. At last, there's some meat on those bones. Watch out, Java!
There's a new boss in town. Real programming languages' specifications
are measured in pounds, and not a page count.
Watch out Java? Watch out Perl more like! The title of most write only language could soon change!
Being serious, I haven't even checked whats new in it but going by C++ 2020 it'll be yet more syntactic soup to support features absolutely no one outside
of ivory tower academic discussions asked for. It'll just add yet morecomplexity to compilers, hence more potential bugs and make the C++ learning
curve even steeper meaning yet more new programmers abandon it - or don't even start - for languages such as Python.
On 27/12/2024 14:47, 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!)
This is the latest draft I could find:
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/n5001.pdf>
On Fri, 27 Dec 2024 21:51:10 -0500
Sam <[email protected]> gabbled:
Stefan Ram writes:
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!)
Hip-hip-hooray! Finally, finally they addressed the long-standing
criticism of C++ being too trivial and too simple, and a kids'
language. At last, there's some meat on those bones. Watch out, Java!
There's a new boss in town. Real programming languages' specifications
are measured in pounds, and not a page count.
Watch out Java? Watch out Perl more like! The title of most write only language could soon change!
Being serious, I haven't even checked whats new in it but going by C++ 2020 it'll be yet more syntactic soup to support features absolutely no one outside
of ivory tower academic discussions asked for. It'll just add yet morecomplexity to compilers, hence more potential bugs and make the C++ learning
curve even steeper meaning yet more new programmers abandon it - or don't even start - for languages such as Python.
On 12/28/24 05:19, [email protected] wrote:
On Fri, 27 Dec 2024 21:51:10 -0500
Sam <[email protected]> gabbled:
Stefan Ram writes:
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!)
Hip-hip-hooray! Finally, finally they addressed the long-standing
criticism of C++ being too trivial and too simple, and a kids'
language. At last, there's some meat on those bones. Watch out, Java!
There's a new boss in town. Real programming languages' specifications
are measured in pounds, and not a page count.
Watch out Java? Watch out Perl more like! The title of most write only
language could soon change!
Being serious, I haven't even checked whats new in it but going by C++ 2020 >> it'll be yet more syntactic soup to support features absolutely no one
outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make the C++
learning
curve even steeper meaning yet more new programmers abandon it - or don't
even start - for languages such as Python.
I'm still on C++98 and C++03. Everything beyond that is just bloat to
me. ;-)
On 28/12/2024 11:19, [email protected] wrote:
Being serious, I haven't even checked whats new in it but going by C++ 2020 >> it'll be yet more syntactic soup to support features absolutely no one
outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make the C++
learning
curve even steeper meaning yet more new programmers abandon it - or don't
even start - for languages such as Python.
Ah, yes - the classic well-reasoned argument. Why would one ever want
to /look/ at the new standard before condemning it?
It's inevitable that most people won't have need of most of the new
features - C++ is a big language, and has a big standard library, and
few people use more than a fraction of it. But all the new features
will be of some use to some people. (It's a lot like Python in that
aspect.)
On Sat, 28 Dec 2024 16:20:57 +0100
David Brown <[email protected]> gabbled:
On 28/12/2024 11:19, [email protected] wrote:
Being serious, I haven't even checked whats new in it but going by
C++ 2020
it'll be yet more syntactic soup to support features absolutely no
one outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make the
C++ learning
curve even steeper meaning yet more new programmers abandon it - or
don't
even start - for languages such as Python.
Ah, yes - the classic well-reasoned argument. Why would one ever want
to /look/ at the new standard before condemning it?
Ah yes, the same logic that has produced cars with ever more, harder to use complexity that no one wants.
On Sat, 28 Dec 2024 13:05:37 -0500
Phillip <[email protected]> gabbled:
I'm still on C++98 and C++03. Everything beyond that is just bloat to me. ;-)
I would say that C++ 11 did improve things particularly wrt the STL and possibly 2014 was the high point. Beyond that its been as you say pointless bloat that achieves nothing.
Benutzer Eins wrote this post while blinking in Morse code:
On 27/12/2024 14:47, 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!)
This is the latest draft I could find:
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/n5001.pdf>
It's only 2400 pages :-(
[email protected] writes:
On Sat, 28 Dec 2024 13:05:37 -0500
Phillip <[email protected]> gabbled:
I'm still on C++98 and C++03. Everything beyond that is just bloat to me. >;-)
I would say that C++ 11 did improve things particularly wrt the STL and
possibly 2014 was the high point. Beyond that its been as you say pointless >> bloat that achieves nothing.
I would say that C++17 was also an incremental improvement.
But C++20 jumped the shark, when the standardization process was hijacked by >Microsoft in order to cram coroutines into the language, which noone wanted, >cared, or asked for, simply because the standard threading model in Windows >blows chunks, performance wise, and Microsoft desperately needed a >multithreading model that did not suck.
On Sun, 29 Dec 2024 08:50:16 -0500
Sam <[email protected]> gabbled:
But C++20 jumped the shark, when the standardization process was hijacked by >> Microsoft in order to cram coroutines into the language, which noone wanted, >> cared, or asked for, simply because the standard threading model in Windows >> blows chunks, performance wise, and Microsoft desperately needed a
multithreading model that did not suck.
I looked at co-routines and wondered wtf the author(s) was smoking. How its supposed to be simpler than simply using a local state machine beats the fsckout of me.
On Sun, 2024-12-29 at 16:17 +0000, [email protected] wrote:
On Sun, 29 Dec 2024 22:33:05 +0800yet?
wij <[email protected]> gabbled:
with that. The wrong thing is regarding it as better new technology, es= >peci=3D=20
ally
when libwy is more advanced (idea) than c++standard library by one gene= >rati=3D
on.
Nobody gives a rats arse about your library. Haven't you figured that out=
=20
No problem for me. I just see you people suffering there, maybe enjoying.
[email protected] writes:
I looked at co-routines and wondered wtf the author(s) was smoking. How its >> supposed to be simpler than simply using a local state machine beats the
fsckout of me.
Everything will make sense to you when you look at the co-routines
proposal, and note its authorship:
https://isocpp.org/files/papers/N4402.pdf
Visual C++ does not have an impressive track record of zippy adoptions of
new C++ language feature. Most of the time it gets beaten to the punch by >gcc. Weirdly, it was the first out of the gate with co-routines.
As I said: std::thread blows chunks on Windows. This was Microsoft's >solution.
But what you don't get to do - or at least, don't get to do if you want
to be viewed seriously - is spout an /uninformed/ opinion. That's no
more than mindless prejudice, and of no interest to anyone.
with that. The wrong thing is regarding it as better new technology, especi= >ally
when libwy is more advanced (idea) than c++standard library by one generati= >on.
[email protected] writes:
On Sun, 29 Dec 2024 08:50:16 -0500
Sam <[email protected]> gabbled:
But C++20 jumped the shark, when the standardization process was
hijacked by Microsoft in order to cram coroutines into the
language, which noone wanted, cared, or asked for, simply because
the standard threading model in Windows blows chunks, performance
wise, and Microsoft desperately needed a multithreading model that
did not suck.
I looked at co-routines and wondered wtf the author(s) was smoking.
How its supposed to be simpler than simply using a local state
machine beats the fsckout of me.
Everything will make sense to you when you look at the co-routines
proposal, and note its authorship:
https://isocpp.org/files/papers/N4402.pdf
Visual C++ does not have an impressive track record of zippy
adoptions of new C++ language feature. Most of the time it gets
beaten to the punch by gcc. Weirdly, it was the first out of the gate
with co-routines.
As I said: std::thread blows chunks on Windows. This was Microsoft's solution.
You can have an informed opinion about C++, and agree or disagree with
the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you want
to be viewed seriously - is spout an /uninformed/ opinion. That's no
more than mindless prejudice, and of no interest to anyone.
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> gabbled:
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
Ah ok , its the usual "anyone who disagrees with me POV is ignorant"
position
is it?
On 29/12/2024 17:16, [email protected] wrote:
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> gabbled:
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
Ah ok , its the usual "anyone who disagrees with me POV is ignorant"
position
is it?
It's not a matter of agreement or disagreement. You know - by your own >admission - /nothing/ about C++23. Your ignorance is not a matter of
opinion but a matter of fact.
I'm not disagreeing about your /opinions/ of C++23 - I am simply stating
that any opinions you have, until you have learned at least a little
about the new standard, are totally worthless.
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
On 29/12/2024 10:32, [email protected] wrote:
On Sat, 28 Dec 2024 16:20:57 +0100
David Brown <[email protected]> gabbled:
On 28/12/2024 11:19, [email protected] wrote:
Being serious, I haven't even checked whats new in it but going
by C++ 2020
it'll be yet more syntactic soup to support features absolutely
no one outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make
the C++ learning
curve even steeper meaning yet more new programmers abandon it -
or don't
even start - for languages such as Python.
Ah, yes - the classic well-reasoned argument.� Why would one ever
want to /look/ at the new standard before condemning it?
Ah yes, the same logic that has produced cars with ever more,
harder to use complexity that no one wants.
No, not remotely. But then, you knew that before making what you
mistakenly thought was a smart or witty reply.
If you don't like the complexity of newer C++ standards, that's fine.
If you don't think it is a good direction for the language, fair
enough. You can choose a different language, or stick to an older
standard, or make your own language, or get involved in the C++ standardisation processes and try to influence them.
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
So go away, and read about C++23. Learn what is new or changed.
/Then/ you can come back and tell us what you don't like about it -
or perhaps you'll find some things that you /do/ like about it.
Either way, you'll be at least vaguely qualified to express an
opinion on it.
<https://en.wikipedia.org/wiki/C%2B%2B23>
On Mon, 30 Dec 2024 00:12:31 +0200
Paavo Helde <[email protected]> wrote:
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
It seems that [email protected] still didn't figure out why
stating strong opinion about something that you not just didn't learn
in depth, but didn't even look at casually is less than optimal.
Michael S <[email protected]> writes:
On Mon, 30 Dec 2024 00:12:31 +0200
Paavo Helde <[email protected]> wrote:
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
It seems that [email protected] still didn't figure out why
stating strong opinion about something that you not just didn't learn
in depth, but didn't even look at casually is less than optimal.
For some time now I have simply stopped reading his comments.
I don't know why anyone bothers with him for more than a handful
of interactions.
Personal opinion: the comments from David Brown do more harm than
good here. At some level he is just a guilty of giving a preachy
opinion as the person he is responding to. It seems likely that
his statements will exacerbate the offending behavior rather than
diminish it.
On Mon, 30 Dec 2024 08:34:32 +0100
David Brown <[email protected]> gabbled:
On 29/12/2024 17:16, [email protected] wrote:
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> gabbled:
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
Ah ok , its the usual "anyone who disagrees with me POV is ignorant"
position
is it?
It's not a matter of agreement or disagreement. You know - by your
own admission - /nothing/ about C++23. Your ignorance is not a matter
of opinion but a matter of fact.
I'm going by 2017 and 2020 adding little of value to the language. I very much doubt they've suddenly found some paradigm changing additions.
I'm not disagreeing about your /opinions/ of C++23 - I am simply
stating that any opinions you have, until you have learned at least a
little about the new standard, are totally worthless.
So you think I've never browsed anything to do with 23? Thats a hell of an assumption.
On 30/12/2024 10:34, [email protected] wrote:
On Mon, 30 Dec 2024 08:34:32 +0100
David Brown <[email protected]> gabbled:
On 29/12/2024 17:16, [email protected] wrote:
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> gabbled:
But what you don't get to do - or at least, don't get to do if youAh ok , its the usual "anyone who disagrees with me POV is ignorant"
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone. >>>>
position
is it?
It's not a matter of agreement or disagreement. You know - by your
own admission - /nothing/ about C++23. Your ignorance is not a matter
of opinion but a matter of fact.
I'm going by 2017 and 2020 adding little of value to the language. I very
much doubt they've suddenly found some paradigm changing additions.
I'm not disagreeing about your /opinions/ of C++23 - I am simply
stating that any opinions you have, until you have learned at least a
little about the new standard, are totally worthless.
So you think I've never browsed anything to do with 23? Thats a hell of an >> assumption.
You wrote: "Being serious, I haven't even checked whats new in it..." >followed by assumptions about C++23. The only assumption /I/ made was
that you were telling the truth - was that unreasonable?
On Mon, 30 Dec 2024 03:17:17 -0800
Tim Rentsch <[email protected]> wibbled:
Michael S <[email protected]> writes:
On Mon, 30 Dec 2024 00:12:31 +0200
Paavo Helde <[email protected]> wrote:
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
It seems that [email protected] still didn't figure out why
stating strong opinion about something that you not just didn't learn
in depth, but didn't even look at casually is less than optimal.
For some time now I have simply stopped reading his comments.
I don't know why anyone bothers with him for more than a handful
of interactions.
The same could be said about you.
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> wrote:
On 29/12/2024 10:32, [email protected] wrote:
On Sat, 28 Dec 2024 16:20:57 +0100
David Brown <[email protected]> gabbled:
On 28/12/2024 11:19, [email protected] wrote:
Being serious, I haven't even checked whats new in it but going
by C++ 2020
it'll be yet more syntactic soup to support features absolutely
no one outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make
the C++ learning
curve even steeper meaning yet more new programmers abandon it -
or don't
even start - for languages such as Python.
Ah, yes - the classic well-reasoned argument. Why would one ever
want to /look/ at the new standard before condemning it?
Ah yes, the same logic that has produced cars with ever more,
harder to use complexity that no one wants.
No, not remotely. But then, you knew that before making what you
mistakenly thought was a smart or witty reply.
If you don't like the complexity of newer C++ standards, that's fine.
If you don't think it is a good direction for the language, fair
enough. You can choose a different language, or stick to an older
standard, or make your own language, or get involved in the C++
standardisation processes and try to influence them.
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
So go away, and read about C++23. Learn what is new or changed.
/Then/ you can come back and tell us what you don't like about it -
or perhaps you'll find some things that you /do/ like about it.
Either way, you'll be at least vaguely qualified to express an
opinion on it.
<https://en.wikipedia.org/wiki/C%2B%2B23>
Comments after cursory view:
C++20 introduces two promising language features - concepts and
coroutines. Both were introduces without proper support in standard
library. Absence of support in library in both cases was justified by probably correct claim that the best library constructs are still in
research state, non-crystallized. The hope was that universal
availability of this features at compiler level will help to best
library constructs to mature.
In case of coroutines developers were left with choice of 3 options:
1. To write a lot of boiler-plate code each time they a going to use coroutines.
2. To try to organize repetitive patterns in the library (likely
template library) of their own and reuse it between parts of the
programs and multiple projects. Hopefully, share with community.
Hopefully, under liberal license.
3. Don't use coroutines
In case of concepts, the choice was even narrower:
1. Use concepts when you occasionally are writing container-like or algorithm-like template of your own.
2. Don't use concepts.
Nobody was realistically expecting that grassroots developers will use concepts to develop comprehensive widely reusable library that
duplicates functionality of STL, but brings advantage of sane error
messages.
So, where we are 3 years later?
W.r.t. concepts, in the same unfortunate place.
W.r.t. coroutines, library provides std::generator. I didn't look at it
yet. Hopefully, it works. Hopefully it is easy to use. But it is just
one of many possible uses of coroutines, and I would think that
it is not the one that could be considered most common.
Did I miss something?
On Mon, 30 Dec 2024 15:37:45 +0100...
David Brown <[email protected]> wibbled:
You wrote: "Being serious, I haven't even checked whats new in it..."
followed by assumptions about C++23. The only assumption /I/ made was
that you were telling the truth - was that unreasonable?
I'd skimmed the wiki entry, nothing in depth. It was enough. But hey, they've renamed puts() to println() so win! Not.
On 12/30/2024 3:14 AM, Tim Rentsch wrote:
[...]
Personal opinion: the comments from David Brown do more harm than
good here. At some level he is just a guilty of giving a preachy
opinion as the person he is responding to. It seems likely that
his statements will exacerbate the offending behavior rather than
diminish it.
I had some arguments with David Brown. Everything was rather
cordial. No flame wars, or anything like that.
On Mon, 30 Dec 2024 03:17:17 -0800
Tim Rentsch <[email protected]> wibbled:
Michael S <[email protected]> writes:
On Mon, 30 Dec 2024 00:12:31 +0200
Paavo Helde <[email protected]> wrote:
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
It seems that [email protected] still didn't figure out why
stating strong opinion about something that you not just didn't learn
in depth, but didn't even look at casually is less than optimal.
For some time now I have simply stopped reading his comments.
I don't know why anyone bothers with him for more than a handful
of interactions.
The same could be said about you.
On Mon, 30 Dec 2024 00:12:31 +0200
Paavo Helde <[email protected]> wrote:
On 29.12.2024 15:51, David Brown wrote:
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to
anyone.
Thanks David, for standing against the trolls. It's a pity that
personal freedoms are often interpreted as "my ignorant opinion has
exactly the same worth as your expert knowledge".
I'm all for personal freedoms, but my freedoms end where they might
hurt other people, or the nature for that matter. Boasting ignorant
jumble can easily do that.
It seems that [email protected] still didn't figure out why
stating strong opinion about something that you not just didn't learn
in depth, but didn't even look at casually is less than optimal.
"Chris M. Thomasson" <[email protected]> writes:
On 12/30/2024 3:14 AM, Tim Rentsch wrote:
[...]
Personal opinion: the comments from David Brown do more harm than
good here. At some level he is just a guilty of giving a preachy
opinion as the person he is responding to. It seems likely that
his statements will exacerbate the offending behavior rather than
diminish it.
I had some arguments with David Brown. Everything was rather
cordial. No flame wars, or anything like that.
Please note that my comments were not about David Brown in general
but only about the statements of his that were quoted in the posting
I was responding to. What I said was not meant as a general
statement, only a specific one, and was not meant about David as a
person but only about the (quoted) words that appeared in the
posting.
On Mon, 30 Dec 2024 15:08:13 -0000 (UTC)
[email protected] wrote:
I'd skimmed the wiki entry, nothing in depth. It was enough. But hey,
they've renamed puts() to println() so win! Not.
Congratulations. You are not an ordinary idiot, but quite extraordinary
one. Not the best, but likely you belong to top 5%.
I'd skimmed the wiki entry, nothing in depth. It was enough. But hey,
they've renamed puts() to println() so win! Not.
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.
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!)
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!)
On 27 Dec 2024 14:47:51 GMT
[email protected] (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.
On Wed, 1 Jan 2025 18:25:27 +0200
Michael S <[email protected]> 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.
On 01.01.2025 18:25, Michael S wrote:
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.
Half of the slowness of both in C printf() and C++ streams comes from
the locale support, which is often unneeded and would just slow things
down. If I have understood correctly, std::print() does not use locale
by default, so has a chance to be much faster. If so, then definitely
this is a step in the right direction.
Half of the slowness of both in C printf() and C++ streams comes
from the locale support, [...]
On 01/01/2025 17:33, [email protected] wrote:
On Wed, 1 Jan 2025 18:25:27 +0200
Michael S <[email protected]> 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
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.
Paavo Helde <[email protected]> writes:
[...]
Half of the slowness of both in C printf() and C++ streams comes
from the locale support, [...]
I find this assertion very hard to believe (specifically, for
printf(); I might guess that C++ streams have similar
performance characteristics, but I don't have nearly as much
experience with C++ streams as I do with printf()).
Is there anything else you can say about it besides an
unsupported assertion?
We resolved it finally by using std::to_chars() for integer data and
Google's double-conversion library for floating-point data (our C++ implementations did not support std::to_chars() on floating-point
data on all needed platforms at that time).
On Thu, 2 Jan 2025 08:06:05 +0100
David Brown <[email protected]> gabbled:
On 01/01/2025 17:33, [email protected] wrote:
On Wed, 1 Jan 2025 18:25:27 +0200
Michael S <[email protected]> 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].
On 02/01/2025 10:23, [email protected] 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.
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;").
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.
According to "The Design and Evolution of C++", Unix redirection
operators were a major inspiration for the choice of << and >>.
Why would it?
It would be a significant change to the syntax and grammar of the
language, complicating parsing, analysis and compilation. And they
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.
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
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
On Thu, 2 Jan 2025 12:31:08 +0200
Paavo Helde <[email protected]> wrote:
We resolved it finally by using std::to_chars() for integer data and
Google's double-conversion library for floating-point data (our C++
implementations did not support std::to_chars() on floating-point
data on all needed platforms at that time).
What do you consider "resolved" ?
Suppose, we write to modern M.2 SSD. Not top speed, like Corsair MP700
Pro, but something more modest, like Samsung 990 Pro. Sequential write
speed of this popular SSD is close to 7 GB/s.
Is the problem considered "resolved" when you are able to write your
CVS at 2 GB/s, i.e. ~30% of what is theoretically possible?
Me thinks, not quite. Client that paid for SSD would still be
disappointed.
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.
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,
On Thu, 2 Jan 2025 13:51:53 +0100
David Brown <[email protected]> wrote:
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,
It does not look like dependence of std::format on compile-time
evaluation is a requirement of standard rather than implementation
choice of g++ and of clang++.
MSVC 19.30.30706 compiles the following code just fine:
#include <cstdio>
#include <format>
int main(int argc, char** argv)
{
if (argc >= 3) {
std::string s = std::format(argv[1], argv[2]);
printf("%s\n", s.c_str());
}
return 0;
}
When run, it produces expected results.
Or, may be, it's because this version of MSVC is not fully C++20
complient.
On 02/01/2025 15:07, [email protected] 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.
The meaning of "cout << 0xFF << 2 << 1234;" is obviously a chain of
outputs - output 0xff, output 2, output 1234. Regardless of the
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.
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
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
On Thu, 2 Jan 2025 13:51:53 +0100
David Brown <[email protected]> wibbled:
On 02/01/2025 10:23, [email protected] 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.
On 02/01/2025 16:35, Michael S wrote:
On Thu, 2 Jan 2025 13:51:53 +0100
David Brown <[email protected]> wrote:
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,
It does not look like dependence of std::format on compile-time
evaluation is a requirement of standard rather than implementation
choice of g++ and of clang++.
MSVC 19.30.30706 compiles the following code just fine:
#include <cstdio>
#include <format>
int main(int argc, char** argv)
{
if (argc >= 3) {
std::string s = std::format(argv[1], argv[2]);
printf("%s\n", s.c_str());
}
return 0;
}
When run, it produces expected results.
Or, may be, it's because this version of MSVC is not fully C++20
complient.
<https://en.cppreference.com/w/cpp/utility/format/format>
Apparently P2216R3 made compile-time checks for std::format a
requirement. I don't know where that fits with standard versions, or compiler support. I am just going by what it says in the reference
here.
On 02/01/2025 15:07, [email protected] 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.
On 01.01.2025 18:25, Michael S wrote:
On 27 Dec 2024 14:47:51 GMT
[email protected] (Stefan Ram) wrote:
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.
Half of the slowness of both in C printf() and C++ streams comes from
Rosario19 <[email protected]d> writes:
On 27 Dec 2024 14:47:51 GMT, (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!)
ot i prefer
https://en.cppreference.com/w/c/23
That has information about C23. Did you mean
https://en.cppreference.com/w/cpp/23
which describes C++23?
(If you meant to say that you prefer C over C++, that's not helpful.)
David Brown <[email protected]> writes:
[...]
IMHO the real mistake for iostreams for formatted output was making
them modal - IO manipulators are a /terrible/ idea.
Agreed.
The type system
and overloading should have been used instead, so that we would write
:
cout << hex(x);
instead of
cout << hex << x << dec;
Note that the latter sets cout to decimal mode, not to whatever mode it
had before.
[email protected] writes:
[...]
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.
<= is already an operator. <<< and >>> are not, but at least >>>
exists in some other languages, which could lead to confusion
(admittedly that's not a very strong argument).
I wouldn't have minded having new operators for I/O, but I'm not sure
what characters would have been used. Perhaps something involving
"@"?
[email protected] writes:
On Thu, 2 Jan 2025 17:54:18 +0100
David Brown <[email protected]> wibbled:
On 02/01/2025 15:07, [email protected] 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?
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.
std::cout << 255 << 1 << std::endl;
Thats perverse.
Apparently your expectation was incorrect.
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?
David Brown writes:
On 02/01/2025 15:07, [email protected] 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.
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).
David Brown writes:
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).
It should be painfully obvious that the right thing to do should've been
to merge throw specifications into function signatures, allowing
exception handling to be validated at compile-time, i.e. what Java did. Instead of that we have the current state of affairs where the only
half-assed solution is to have all exception classes derived from a superclass, i.e. std::exception, and then play musical chairs to catch exceptions.
Paavo Helde writes:
Here's a free clue. Define "function X throws exception Y" if it throws that >exception (and it doesn't catch it itself), or if it calls function Z that's >declared (in Z's throw specifier) as throwing that exception. The compiler >has all the information needed to know which exception can be thrown out of >that function.
This is not C. This is C++. The compiler has the signature of every function >called by code.
David Brown writes:
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).
It should be painfully obvious that the right thing to do should've been
to merge throw specifications into function signatures, allowing
exception handling to be validated at compile-time, i.e. what Java did.
Instead of that we have the current state of affairs where the only half-assed solution is to have all exception classes derived from a superclass, i.e. std::exception, and then play musical chairs to catch exceptions.
It might be obvious to you, but not for everybody. What exact problem can be solved by validating thrown exception classes at compile time?
And how would a developer of a base class know which exceptions I might want to throw from an overridden virtual function in a derived class, which might be developed and compiled fully separately from the base class?
half-assed solution is to have all exception classes derived from a superclass, i.e. std::exception, and then play musical chairs to catch exceptions.
My Java is rusty, but isn't it in Java that all exception classes must be derived from a single superclass (Throwable)?
That's wrong on many levels.
First, what you think should be "obvious" now might not have been obvious at the time the relevant decisions were made - it's a lot easier to see
problems with hindsight than to predict them in advance.
A full throw specifier can also be validated for correctness, in the same >exact FUCKING way, at compile time. This would look like…
On Fri, 03 Jan 2025 11:53:11 -0500
Sam <[email protected]> gabbled:
A full throw specifier can also be validated for correctness, in the same
exact FUCKING way, at compile time. This would look like…
You seem to be getting very worked up about it. I don't know about java but in C++ exceptions are just that - for exceptional circumstances. They're not supposed to be used as glorified return statements so should be rarely used anyway so frankly who gives a fuck about sigs?
On Fri, 03 Jan 2025 10:50:51 -0500
Sam <[email protected]> wibbled:
Paavo Helde writes:
Here's a free clue. Define "function X throws exception Y" if it throws that >exception (and it doesn't catch it itself), or if it calls function Z that's >declared (in Z's throw specifier) as throwing that exception. The compiler >has all the information needed to know which exception can be thrown out of >that function.
This is not C. This is C++. The compiler has the signature of every function >called by code.
It needs more than that when function pointers are involved. It cannot
necessarily know at compile time which function will be assigned to the pointer so how is it supposed to know if the exception sig is valid?
Unless
you're suggesting also have an exception sig for function pointers which would
probably break a whole load of code and make life difficult for zero gain.
I'll go even as far as stating, that either:
A) I'm missing something obvious, something fundamental to C++ that
would've prevented this implementation.
B) The original implementation of throw specifiers in C++ was written by (fill in your favorite perjorative here, mine is "morons").
On 03/01/2025 16:50, Sam wrote:
I'll go even as far as stating, that either:
A) I'm missing something obvious, something fundamental to C++ that would've >> prevented this implementation.
B) The original implementation of throw specifiers in C++ was written by
(fill in your favorite perjorative here, mine is "morons").
The answer is obviously A.
Be a little less obnoxious in your posts, and maybe someone will explain it to you (if you are unable to understand the posts I've already made).
Paavo Helde writes:
It might be obvious to you, but not for everybody. What exact problem
can be solved by validating thrown exception classes at compile time?
Ummm… Making it logically impossible to throw an uncaught exception? The code will refuse to compile because it will be ill-formed. Getting rid
of std::uncaught_exception(), completely?
And how
would a developer of a base class know which exceptions I might want
to throw from an overridden virtual function in a derived class, which
might be developed and compiled fully separately from the base class?
The developer doesn't need to figure it out, the compiler will tell him.
On 03.01.2025 17:50, Sam wrote:
Paavo Helde writes:
It might be obvious to you, but not for everybody. What exact problem can be
solved by validating thrown exception classes at compile time?
Ummm… Making it logically impossible to throw an uncaught exception? The >> code will refuse to compile because it will be ill-formed. Getting rid of
std::uncaught_exception(), completely?
I have never used std::uncaught_exception().
Well, I think I tried to use it once, 20 years ago, but it did not work in any useful way IIRC.
Anyway, avoiding uncaught exceptions is easy, one just has to place catch(...) in main() and in all thread functions. Problem solved.
Double exceptions appearing during stack unwind are more tricky. Here some compiler support enforcing noexcept would be nice indeed. But this would not need any more detailed exception specifications.
And how would
a developer of a base class know which exceptions I might want to throw from
an overridden virtual function in a derived class, which might be developed >>> and compiled fully separately from the base class?
The developer doesn't need to figure it out, the compiler will tell him.
You misunderstood my point. Yes, the compiler will refuse to compile my code because a new algorithm implementation throws a new kind of SocketException or whatever. So what next?
The goal is to compile my code, not to get compiler errors.
Now I have to change the signatures of the umpteen functions in the call stack in umpteen classes in umpteen projects to let the new required exception through (or translate it to something else via an even more questionable hack).
The point is that those umpteen functions could not care less about what exceptions go through them as they will just pass them all through. So what's the point?
At any frame in the call stack, if I want to catch a specific exception, I can do that. Everything else goes up to the top-level catch(...) and gets logged or converted to an error message as appropriate.
Why should I arbitrarily restrict what exceptions I can throw in some function?
[email protected] writes:
On Fri, 03 Jan 2025 11:53:11 -0500
Sam <[email protected]> gabbled:
A full throw specifier can also be validated for correctness, in the same >>> exact FUCKING way, at compile time. This would look like…
You seem to be getting very worked up about it. I don't know about java but >> in C++ exceptions are just that - for exceptional circumstances. They're not >> supposed to be used as glorified return statements so should be rarely used >> anyway so frankly who gives a fuck about sigs?
You convinced me. Let's just get rid of function signatures entirely. It's >time to get to basics, the K&R way.
[email protected] writes:
On Thu, 02 Jan 2025 13:38:17 -0800[...]
Keith Thompson <[email protected]> wibbled:
I wouldn't have minded having new operators for I/O, but I'm not sure >>>what characters would have been used. Perhaps something involving
"@"?
It doesn't have to be pretty, so long as its unique.
It doesn't have to be unique, as demonstrated by several decades of >experience with << and >>.
In my opinion, legibility and ease of typing are more important than >uniqueness. << and >> are easier to type and more visually suggestive
than, say, @< and @>.
Note that operators don't have to consist of punctuation symbols (see
sizeof, new, etc.). An alternative might have been to introduce "in"
and "out" operators in place of ">> and "<<". But I wouldn't suggest
making such a change now.
[email protected] 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.
On Fri, 03 Jan 2025 11:22:09 -0800
Keith Thompson <[email protected]> gabbled:
[email protected] 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 >>.
On 04/01/2025 11:17, [email protected] wrote:
On Fri, 03 Jan 2025 11:22:09 -0800
Keith Thompson <[email protected]> gabbled:
[email protected] 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?
David Brown writes:
On 03/01/2025 16:50, Sam wrote:
I'll go even as far as stating, that either:
A) I'm missing something obvious, something fundamental to C++ that
would've prevented this implementation.
B) The original implementation of throw specifiers in C++ was written
by (fill in your favorite perjorative here, mine is "morons").
The answer is obviously A.
Maybe to a super-genius like yourself, but mere mortals may have some
trouble figuring it out.
Be a little less obnoxious in your posts, and maybe someone will
explain it to you (if you are unable to understand the posts I've
already made).
Sir: this is Usenet, and not Facebook. Go down the hall, last door on
your left.
On Sat, 4 Jan 2025 12:31:33 +0100
David Brown <[email protected]> gabbled:
On 04/01/2025 11:17, [email protected] wrote:
On Fri, 03 Jan 2025 11:22:09 -0800
Keith Thompson <[email protected]> gabbled:
[email protected] 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.
On 03/01/2025 19:58, Sam wrote:
David Brown writes:
On 03/01/2025 16:50, Sam wrote:
I'll go even as far as stating, that either:
A) I'm missing something obvious, something fundamental to C++ that would've
prevented this implementation.
B) The original implementation of throw specifiers in C++ was written by >>>> (fill in your favorite perjorative here, mine is "morons").
The answer is obviously A.
Maybe to a super-genius like yourself, but mere mortals may have some
trouble figuring it out.
Right. The super-geniuses - like Stroustrup and his colleagues - understood what they were doing. They understood that any language design decision is
a compromise, and picked the balance that they believed worked best for the kind of language they were creating. Then 40-odd years later some mere mortal comes along and says they were all morons.
I don't need to be a super-genius to see that the answer is obviously A.
Be a little less obnoxious in your posts, and maybe someone will explain it >>> to you (if you are unable to understand the posts I've already made).
Sir: this is Usenet, and not Facebook. Go down the hall, last door on your >> left.
I can't stop you being obnoxious in your posts. But I /can/ tell you it greatly reduces your chances of getting helpful answers to your posts.
On 04/01/2025 12:34, [email protected] wrote:
On Sat, 4 Jan 2025 12:31:33 +0100
David Brown <[email protected]> gabbled:
On 04/01/2025 11:17, [email protected] wrote:
On Fri, 03 Jan 2025 11:22:09 -0800
Keith Thompson <[email protected]> gabbled:
[email protected] 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?
Paavo Helde writes:
Anyway, avoiding uncaught exceptions is easy, one just has to place
catch(...) in main() and in all thread functions. Problem solved.
Sure, catch(...) deals with it. But it gives you nothing useful to work
with. A valiant attempt to send a bat-signal to std::current_exception
will eke out a few useful bits, if one's lucky, but the end result will
just be more spaghetti code.
I dunno, maybe something like:
typedef throws(ClassA, ClassB) AlgoThrownClasses;
Then you go ahead and declare your algorithm:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
On 04.01.2025 04:06, Sam wrote:
Paavo Helde writes:
Anyway, avoiding uncaught exceptions is easy, one just has to place
catch(...) in main() and in all thread functions. Problem solved.
Sure, catch(...) deals with it. But it gives you nothing useful to work
with. A valiant attempt to send a bat-signal to std::current_exception will >> eke out a few useful bits, if one's lucky, but the end result will just be >> more spaghetti code.
If an exception has reached the top-level catch, then this means that all lower levels (which have more knowledge about the context) have not been
able to catch and handle it. In the top-level catch there is little hope I could do anything smarter, typically I just need to report or log an error message.
So there is no need to differentiate between different types of exceptions
or to extract any useful bits from them, all I need is an error message. For that I have a little helper function which can be called from inside catch(...) and which handles various exception base classes and falls back
to typeid(e).name() for unknown types. Actually I am not interested in exception types at all at this point, not to speak about enforcing them somehow. If there appear new exception base classes, I add support for them in the helper function, not trying to reduce their usage.
[...]
I dunno, maybe something like:
typedef throws(ClassA, ClassB) AlgoThrownClasses;
Then you go ahead and declare your algorithm:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not see much point in exception specifications, but such a typedef would at least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
On 30/12/2024 12:25, Michael S wrote:
On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <[email protected]> wrote:
Comments after cursory view:
C++20 introduces two promising language features - concepts and
coroutines. Both were introduces without proper support in standard library. Absence of support in library in both cases was justified
by probably correct claim that the best library constructs are
still in research state, non-crystallized. The hope was that
universal availability of this features at compiler level will help
to best library constructs to mature.
In case of coroutines developers were left with choice of 3 options:
1. To write a lot of boiler-plate code each time they a going to use coroutines.
2. To try to organize repetitive patterns in the library (likely
template library) of their own and reuse it between parts of the
programs and multiple projects. Hopefully, share with community.
Hopefully, under liberal license.
3. Don't use coroutines
In case of concepts, the choice was even narrower:
1. Use concepts when you occasionally are writing container-like or algorithm-like template of your own.
2. Don't use concepts.
Nobody was realistically expecting that grassroots developers will
use concepts to develop comprehensive widely reusable library that duplicates functionality of STL, but brings advantage of sane error messages.
So, where we are 3 years later?
W.r.t. concepts, in the same unfortunate place.
W.r.t. coroutines, library provides std::generator. I didn't look
at it yet. Hopefully, it works. Hopefully it is easy to use. But it
is just one of many possible uses of coroutines, and I would think
that it is not the one that could be considered most common.
Did I miss something?
I have no experience with coroutines, so I can't really judge them.
They do not appear to me to be a "thread alternative" - rather, they
are trying to get the kind of lightweight asynchronous support that
is increasingly popular in other languages (Python, Go, Javascript,
etc.). Like C++ threading, locks and atomics, they don't really fit
in the kind of system I work with.
On 04.01.2025 04:06, Sam wrote:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not
see much point in exception specifications, but such a typedef would at
least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
On Sat, 4 Jan 2025 20:08:00 +0200
Paavo Helde <[email protected]> wibbled:
On 04.01.2025 04:06, Sam wrote:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not
see much point in exception specifications, but such a typedef would at >>least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
I never understood the point of that. Why not increase the semantic scope
of "typedef" instead of having 2 keywords that in a lot of circumstances
do the same thing?
[email protected] wrote this post while blinking in Morse code:
On Sat, 4 Jan 2025 20:08:00 +0200
Paavo Helde <[email protected]> wibbled:
On 04.01.2025 04:06, Sam wrote:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not >>>see much point in exception specifications, but such a typedef would at >>>least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
I never understood the point of that. Why not increase the semantic scope
of "typedef" instead of having 2 keywords that in a lot of circumstances
do the same thing?
Because using is a nicer to read?
[email protected] wrote this post while blinking in Morse code:
I never understood the point of that. Why not increase the semantic scope of "typedef" instead of having 2 keywords that in a lot of circumstances
do the same thing?
Because using is a nicer to read?
On 02.01.2025 10:39, Tim Rentsch wrote:
Paavo Helde <[email protected]> writes:
[...]
Half of the slowness of both in C printf() and C++ streams comes
from the locale support, [...]
I find this assertion very hard to believe (specifically, for
printf(); I might guess that C++ streams have similar
performance characteristics, but I don't have nearly as much
experience with C++ streams as I do with printf()).
Is there anything else you can say about it besides an
unsupported assertion?
Probably you were misled by my vague word usage. I said "half of the slowness", not "half of the total time". As "slowness" is nowhere
exactly defined, this was just a figure of speech, no need to get
overly upset about that.
Anyway, I have profiled the writing of large CSV tables (multi-GB)
which was deemed too slow. 90% of time was spent in sprintf() calls,
from which 10% was spent in locale-related routines, presumably for
checking that the global process locale has not changed during the
last microsecond. Considering that our CSV file format had to always
use the fixed C-locale format anyway, this locale checking was
something which was absolutely unneeded.
We tried to parallelize the writing, expecting to increase the speed N
times by using N threads, but alas, as the locale is a global
thread-shared object, now the threads started to fight over it and the performance did not scale nowhere near to our expectations. (The thread-specific locales were not available an all needed platforms).
We resolved it finally by using std::to_chars() for integer data and
Google's double-conversion library for floating-point data (our C++ implementations did not support std::to_chars() on floating-point data
on all needed platforms at that time).
Paavo Helde <[email protected]> writes:
On 02.01.2025 10:39, Tim Rentsch wrote:
Paavo Helde <[email protected]> writes:
[...]
Half of the slowness of both in C printf() and C++ streams comes
from the locale support, [...]
I find this assertion very hard to believe (specifically, for
printf(); I might guess that C++ streams have similar
performance characteristics, but I don't have nearly as much
experience with C++ streams as I do with printf()).
Is there anything else you can say about it besides an
unsupported assertion?
Probably you were misled by my vague word usage. I said "half of the
slowness", not "half of the total time". As "slowness" is nowhere
exactly defined, this was just a figure of speech, no need to get
overly upset about that.
I'm not upset, just disappointed. I consider you one of the better contributors in the newsgroups, and so it's surprising to see a
statement from you with zero information content.
Anyway, I have profiled the writing of large CSV tables (multi-GB)
which was deemed too slow. 90% of time was spent in sprintf() calls,
from which 10% was spent in locale-related routines, presumably for
checking that the global process locale has not changed during the
last microsecond. Considering that our CSV file format had to always
use the fixed C-locale format anyway, this locale checking was
something which was absolutely unneeded.
The 10% number is interesting, and disappointing. Surely the authors
of the standard library implementation could have done better.
Incidentally, I did a measurement of the cost of localeconv() on my
test server (running Ubuntu), and that gave a result in line with
your 10% number.
We tried to parallelize the writing, expecting to increase the speed N
times by using N threads, but alas, as the locale is a global
thread-shared object, now the threads started to fight over it and the
performance did not scale nowhere near to our expectations. (The
thread-specific locales were not available an all needed platforms).
Does the C standard (or the C++ standard) allow locale information to
be thread-specific? I don't see anything in the C standard that looks
like the <locale.h> functions can be anything but global. I haven't
looked at what C++ allows.
We resolved it finally by using std::to_chars() for integer data and
Google's double-conversion library for floating-point data (our C++
implementations did not support std::to_chars() on floating-point data
on all needed platforms at that time).
It's disappointing that the C standard (and I assume also the C++
standard) doesn't provide conversion functions that don't use global
locale information. Oh, come to think of it, I think I saw some C++ functions (in which C++ standard I don't know) that pass locale
information in explicitly, which is probably what you were alluding
to above.
Fast *and* accurate printing of floating-point numbers is not a
trivial task. AFAIK last significant advances in this area were done
as late as in 2010. See e.g. "http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/"
On Tue, 7 Jan 2025 08:40:47 -0500
Chris Ahlstrom <[email protected]> wibbled:
[email protected] wrote this post while blinking in Morse code:
On Sat, 4 Jan 2025 20:08:00 +0200
Paavo Helde <[email protected]> wibbled:
On 04.01.2025 04:06, Sam wrote:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not >>>>see much point in exception specifications, but such a typedef would at >>>>least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
I never understood the point of that. Why not increase the semantic scope >>> of "typedef" instead of having 2 keywords that in a lot of circumstances >>> do the same thing?
Because using is a nicer to read?
Who knows. The C++ committee certainly has form on this - typename replaced class in template definitions when they realised 10 years after everyone else that reusing class in that particular case was somewhat confusing.
On Wed, 8 Jan 2025 08:44:05 +0200
Paavo Helde <[email protected]> wrote:
Fast *and* accurate printing of floating-point numbers is not a
trivial task. AFAIK last significant advances in this area were done
as late as in 2010. See e.g.
"http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/"
I didn't read it, but I want to point that even the question of what is 'accurate' is not trivial when we consider conversion in
non-default rounding modes. I am not sure that C++ standard contains sufficient information about it.
[email protected] wrote this post while blinking in Morse code:
Who knows. The C++ committee certainly has form on this - typename replaced >> class in template definitions when they realised 10 years after everyone else
that reusing class in that particular case was somewhat confusing.
Stroustrup in section 23.2 of his 4th edition C++ book notes that
these two are equivalent:
template<typename X>
template<class X>
but that for typename X, X need not be a class.
On Wed, 8 Jan 2025 08:44:05 +0200
Paavo Helde <[email protected]> wrote:
Fast *and* accurate printing of floating-point numbers is not a
trivial task. AFAIK last significant advances in this area were done
as late as in 2010. See e.g.
"http://www.serpentine.com/blog/2011/06/29/
here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/"
I didn't read it, but I want to point that even the question of what is 'accurate' is not trivial when we consider conversion in
non-default rounding modes. I am not sure that C++ standard contains sufficient information about it.
On 08.01.2025 07:15, Tim Rentsch wrote:
Paavo Helde <[email protected]> writes:
On 02.01.2025 10:39, Tim Rentsch wrote:
Paavo Helde <[email protected]> writes:
[...]
Half of the slowness of both in C printf() and C++ streams comes
from the locale support, [...]
I find this assertion very hard to believe (specifically, for
printf(); I might guess that C++ streams have similar
performance characteristics, but I don't have nearly as much
experience with C++ streams as I do with printf()).
Is there anything else you can say about it besides an
unsupported assertion?
Probably you were misled by my vague word usage. I said "half of the
slowness", not "half of the total time". As "slowness" is nowhere
exactly defined, this was just a figure of speech, no need to get
overly upset about that.
I'm not upset, just disappointed. I consider you one of the better
contributors in the newsgroups, and so it's surprising to see a
statement from you with zero information content.
Anyway, I have profiled the writing of large CSV tables (multi-GB)
which was deemed too slow. 90% of time was spent in sprintf() calls,
from which 10% was spent in locale-related routines, presumably for
checking that the global process locale has not changed during the
last microsecond. Considering that our CSV file format had to always
use the fixed C-locale format anyway, this locale checking was
something which was absolutely unneeded.
The 10% number is interesting, and disappointing. Surely the authors
of the standard library implementation could have done better.
Incidentally, I did a measurement of the cost of localeconv() on my
test server (running Ubuntu), and that gave a result in line with
your 10% number.
We tried to parallelize the writing, expecting to increase the speed N
times by using N threads, but alas, as the locale is a global
thread-shared object, now the threads started to fight over it and the
performance did not scale nowhere near to our expectations. (The
thread-specific locales were not available an all needed platforms).
Does the C standard (or the C++ standard) allow locale information to
be thread-specific? I don't see anything in the C standard that looks
like the <locale.h> functions can be anything but global. I haven't
looked at what C++ allows.
_configthreadlocale() is a MS extension.
"https://learn.microsoft.com/en-us/cpp/
c-runtime-library/reference/configthreadlocale"
We resolved it finally by using std::to_chars() for integer data and
Google's double-conversion library for floating-point data (our C++
implementations did not support std::to_chars() on floating-point data
on all needed platforms at that time).
It's disappointing that the C standard (and I assume also the C++
standard) doesn't provide conversion functions that don't use global
locale information. Oh, come to think of it, I think I saw some C++
functions (in which C++ standard I don't know) that pass locale
information in explicitly, which is probably what you were alluding
to above.
MSVC has _sprintf_l() which takes a locale explicitly, but this is
again a non-standard extension.
Regardless if the locale is passed in implicitly or explicitly, the
function would still need to process it, which might take non-zero
time.
We were aiming to use functions which would not consider locales
at all.
C++ actually delivers that with std::to_chars() since C++17. I have
not measured how fast it is nowadays, compared to Google's
double-conversion.
Fast *and* accurate printing of floating-point numbers is not a
trivial task. AFAIK last significant advances in this area were done
as late as in 2010. See
e.g. "http://www.serpentine.com/blog/2011/06/29/
here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/"
Does your output need to be human readable, or is program readable
good enough? If the consumers can deal with non-decimal formatting,
you could use %a or %A, which is easier and faster to produce.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:32:28 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,775 |