Wednesday, September 16, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 16 08:16PM +0100

Just submitted a VS2019 bug report (C++17 non-conformance):
 
std::cout << a() << "," << b(); // a() is not sequenced before b()
 
/Flibble
 
--
¬
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 16 03:34PM -0400

On 9/16/20 3:16 PM, Mr Flibble wrote:
> Just submitted a VS2019 bug report (C++17 non-conformance):
 
> std::cout << a() << "," << b(); // a() is not sequenced before b()
 
Switch to C and that whole problem goes away, along with a few hundred
thousand?? others.
 
Write In C (Let It Be parody)
https://www.youtube.com/watch?v=1S1fISh-pag
 
C code may be a little more lengthy to accomplish the same task, but
given C++'s syntax, it's actually easier to read, faster to write,
and it makes you happy at the end of the day.
 
Just saying.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 16 08:36PM +0100

On 16/09/2020 20:34, Rick C. Hodgin wrote:
> given C++'s syntax, it's actually easier to read, faster to write,
> and it makes you happy at the end of the day.
 
> Just saying.
 
And Satan invented the fossil record, yes spammer?
 
--
¬
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 16 03:47PM -0400

On 9/16/20 3:36 PM, Mr Flibble wrote:
> And Satan invented the fossil record, yes spammer?
 
No, purposefully ignorant person.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 16 08:49PM +0100

On 16/09/2020 20:16, Mr Flibble wrote:
> Just submitted a VS2019 bug report (C++17 non-conformance):
 
> std::cout << a() << "," << b(); // a() is not sequenced before b()
 
Report is: https://developercommunity.visualstudio.com/content/problem/1187555/vs2019-c-is-not-c17-confornment-operator-argument.html
 
/Flibble
 
--
¬
David Brown <david.brown@hesbynett.no>: Sep 16 09:51PM +0200

On 16/09/2020 21:34, Rick C. Hodgin wrote:
 
>> std::cout << a() << "," << b(); // a() is not sequenced before b()
 
> Switch to C and that whole problem goes away, along with a few hundred
> thousand?? others.
 
C does not require "a()" to be evaluated before "b()" in an expression,
unless there are sequence points (like a comma) to force it. C++ was
the same until C++17, when "left to right" evaluation order was added
specifically because it is what people expect in an expression like
this. (Personally, I'm not sure that was the right solution - perhaps
making << and >> act as sequence points would have been better. But I
suppose the committee thought about that before making the change.)
 
Mr. Flibble is right - if MSVC is evaluating b() before a() in C++17
mode, it's a bug. In C++ before C++17, or in C, the order is unspecified.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 16 08:56PM +0100

>> Just submitted a VS2019 bug report (C++17 non-conformance):
 
>> std::cout << a() << "," << b(); // a() is not sequenced before b()
 
> Switch to C and that whole problem goes away,
 
How so? C has weaker rules about expression evaluation sequencing than
C++ does and none that fix this issue with sequencing IO operations.
 
--
Ben.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 16 03:57PM -0400

On 9/16/20 3:56 PM, Ben Bacarisse wrote:
 
>> Switch to C and that whole problem goes away,
 
> How so? C has weaker rules about expression evaluation sequencing than
> C++ does and none that fix this issue with sequencing IO operations.
 
You wouldn't write IO in that way in C, so the problem goes away.
 
--
Rick C. Hodgin
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 16 09:16PM +0100

> the same until C++17, when "left to right" evaluation order was added
> specifically because it is what people expect in an expression like
> this.
 
I could not find where that is specified (but I have only a draft).
 
> (Personally, I'm not sure that was the right solution - perhaps
> making << and >> act as sequence points would have been better. But I
> suppose the committee thought about that before making the change.)
 
In N4713 both E1 << E2 and E1 >> E2 have explicit statements that E1 is
sequenced before E2 (much like the text for &&, || and the comma
operator as you suggest) but I could find not the general rule you refer
to further up.
 
> Mr. Flibble is right - if MSVC is evaluating b() before a() in C++17
> mode, it's a bug. In C++ before C++17, or in C, the order is
> unspecified.
 
I get confused by the drafts, but N3797, which I thought was a draft of
C++14, has the same explicit wording for << and >>. Maybe N3797 was a
very early draft of C++17.
 
--
Ben.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 16 09:32PM +0100

On 16/09/2020 20:49, Mr Flibble wrote:
>> Just submitted a VS2019 bug report (C++17 non-conformance):
 
>> std::cout << a() << "," << b(); // a() is not sequenced before b()
 
> Report is: https://developercommunity.visualstudio.com/content/problem/1187555/vs2019-c-is-not-c17-confornment-operator-argument.html
 
The problem was operator error: it helps if you change the compiler settings for the build configuration you are actually building.
 
Sorry for the noise.
 
/Flibble
 
--
¬
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 16 09:47PM +0100


>> How so? C has weaker rules about expression evaluation sequencing than
>> C++ does and none that fix this issue with sequencing IO operations.
 
> You wouldn't write IO in that way in C, so the problem goes away.
 
You can write it so that the problem goes away in C++ too, so what was
your point about switching C?
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Sep 16 10:51PM +0200

On 16/09/2020 22:16, Ben Bacarisse wrote:
 
> I get confused by the drafts, but N3797, which I thought was a draft of
> C++14, has the same explicit wording for << and >>. Maybe N3797 was a
> very early draft of C++17.
 
I like it when you challenge me this way - it forces me to go back and
look for the details, and sometimes, like here, makes me realise I've
got things wrong.
 
I think I have been generalising from some "list of new features in
C++17", rather than looking a the real details. C++17 has actually done
pretty much what I said I'd prefer, rather than what I thought it had!
 
Some expression - E1[E2], E1.*E2, E1->*E2, E1 << E2, E1 >> E2, E2 = E1,
and E2 @= E1 (compound assignments) now have E1 sequences before E2 for
evaluation and side effects.
 
<https://en.cppreference.com/w/cpp/language/eval_order>
 
provides a summary that is easier to follow than the standards.
 
MSVC is still wrong, since C++17 forces the evaluation order of <<
expressions.
David Brown <david.brown@hesbynett.no>: Sep 16 10:53PM +0200

On 16/09/2020 22:32, Mr Flibble wrote:
 
> The problem was operator error: it helps if you change the compiler
> settings for the build configuration you are actually building.
 
> Sorry for the noise.
 
The thread made me think, let me make a mistake, let my mistake get
spotted, let me correct my mistake and learn a little more accurate
details. So I am glad for the noise here!
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 16 09:54PM +0100

On 16/09/2020 21:51, David Brown wrote:
 
> provides a summary that is easier to follow than the standards.
 
> MSVC is still wrong, since C++17 forces the evaluation order of <<
> expressions.
 
MSVC is only wrong if you choose language standard compiler setting of pre-C++17. Yes it was operator error. :/
 
/Flibble
 
--
¬
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 16 09:57AM -0400

On 9/14/20 8:58 PM, Chris Vine wrote:
>> that makes that true must lie in some other part of the document.
 
> I don't agree as a matter of English that C++20's [expr.add]/4 has the
> same effect as §6.5.6/8.
 
I didn't say that they had the same effect - only that both descriptions
are "predicated on P pointing at the i'th member of an array". Both
descriptions become meaningless when that is not the case. If you
disagree, what would the value i be when there is no array? What would
the value of n be? What would be the meaning of "array element i+j"?
 
> pointer to any type of object with a fundamental alignment requirement
> and then used to access such an object or an array of such objects in
> the space allocated (until the space is explicitly deallocated)".
 
I'm sorry. I not only forgot about that clause, I forgot that I've
recently been reminded of that clause. After 62 years, my memory is not
what it used to be - and it was never exactly spectacular :-(. I retract
my claim that there's a problem in C.
 
...
> not necessarily suggesting that you should, but do so if you would
> like), can you start from the beginning again without reference to the
> text of prior postings in a concise form.
 
OK - I'll try a different way of saying this.
 
1. In the C++ draft standard n3797.pdf, section 5.7 is about "Additive
Operators"
 
2. 5.7p4 says "For the purposes of these operators, a pointer to a
nonarray object behaves the same as a pointer to the first element of an
array of length one with the type of the object as its element type."
 
3. In the C++ draft standard n4860.pdf, the clauses have been
substantially rearranged, so the section covering "Additive operators"
is now 7.6.6.
 
4. Not only does n4860.pdf 7.6.6p4 not say the same thing that n3797.pdf
5.7p4 used to say, I can't find any equivalent wording anywhere else in
7.6.6, nor, for that matter, anywhere else in the standard. Now, if they
substantially changed the wording, my searches might have failed, so
it's entirely possible that it is there somewhere - but I don't know
where. If you do, please identify the clause.
 
If I'm correct that there is no wording in n4860.pdf that says basically
the same thing that was said in n3797.pdf 5.7p4, then that's a problem.
Here's why. Given the declaration:
 
int i;
 
In both C and C++, it was perfectly conforming behavior to pass &i and
1+&i to an algorithm that expects start and end pointers for an array of
objects. However,
 
5. The expression 1+&i has defined behavior in C only due to 6.5.6p7,
which says "For the purposes of these operators, a pointer to an object
that is not an element of an array behaves the same as a pointer to the
first element of an array of length one with the type of the object as
its element type." (which is essentially the same thing that n3937.pdf
says in 5.7p4 about C++).
 
6. If I'm right about there being no corresponding statement in
n4860.pdf, the latest draft of the C++ standard, then [expr.add]/4
becomes meaningless, because &i doesn't point at any element of any array.
 
7. The behavior of 1+&i is therefore undefined because "... this
document omits any explicit definition of behavior ..." (3.30).
 
Is that any clearer? If not, could you be more specific about what part
of that discussion you find unclear, and why? I've numbered parts of the
discussion for ease of reference.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 16 07:19AM -0700

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
 
[...]
 
> n3797.pdf 5.7p4 used to say, I can't find any equivalent wording
> anywhere else in 7.6.6, nor, for that matter, anywhere else in the
> standard. [...]
 
Not to put too fine a point on it, did you try reading the
footnote referenced in 7.6.6p4?
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 16 10:52AM -0400

On 9/16/20 9:57 AM, James Kuyper wrote:
...
> 2. 5.7p4 says "For the purposes of these operators, a pointer to a
> nonarray object behaves the same as a pointer to the first element of an
> array of length one with the type of the object as its element type."
...
> first element of an array of length one with the type of the object as
> its element type." (which is essentially the same thing that n3937.pdf
> says in 5.7p4 about C++).
I just realized a key (and possibly unintentional) difference. Given:
 
    int myarray[5];
 
The object myarray is an array object, so C++ n3797.pdf 5.7p4 doesn't
apply to &myarray. However, myarray is not an element of an array, so C
6.5.6p7 does apply. That means that in C, &myarray is treated as if it
pointed at the first (and only) element of an array declared as
"int[1][5]", so 1+&myarray points one past the end of that notional 2D
array; but n3797.pdf doesn't allow that in C++. I doubt that this was
intentional, but since that wording has been removed in n4860.pdf, that
doesn't matter.
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Sep 16 10:28AM -0700

On Wednesday, September 16, 2020 at 10:20:18 AM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
...
> > n3797.pdf 5.7p4 used to say, I can't find any equivalent wording
> > anywhere else in 7.6.6, nor, for that matter, anywhere else in the
> > standard. [...]
 
Thank you for snipping the part of my response admitting that my searches might have missed the relevant clause. I love being made to sound absolutely certain about something I've explicitly expressed doubts about.
 
> Not to put too fine a point on it, did you try reading the
> footnote referenced in 7.6.6p4?
 
No - the footnote reference displayed so small that I didn't notice it until the 6th time I checked it after you brought it to my attention, I didn't notice at all before you did so.
The reason my text searches didn't find it is that I was looking for the phrase "array of length one", which has been replaced by "single-element array".
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Sep 16 10:40AM -0700

On Wednesday, September 16, 2020 at 10:53:21 AM UTC-4, james...@alumni.caltech.edu wrote:
...
 
> The object myarray is an array object, so C++ n3797.pdf 5.7p4 doesn't
> apply to &myarray. However, myarray is not an element of an array, so C
> 6.5.6p7 does apply.
 
Thanks to TIm Rentsch for bringing to my attention that, in n4860.pdf, the normative text
has been moved to 6.8.2p3.2, and it now uses the same "not an element of an array" phrase
as the C standard, avoiding this problem and removing that difference.
Juha Nieminen <nospam@thanks.invalid>: Sep 16 10:01AM

> the hardware level in one way or another for forty years building
> mainframes, massively distributed systems and high-core count
> Aarch64 processors.
 
Then why are you asking questions like "where did you get the idea that CPUs
like consecutive memory accesses"?
 
>>The difference in speed is *staggering*.
 
> Indeed, however, this is an artificial benchmark that doesn't
> represent the vast majority of real-world workloads.
 
Which is precisely the problem in the first place! A problem that things like
Data-oriented Design aim to solve. (Or more precisely, to try to make
real-world number-crunching applications, or applications that benefit from
number-crunching, as efficient as possible in modern processors.)
 
That's the very idea: There's a huge amount of wasted potential in modern
CPUs that computation-heavy programs could tap into, if they just had been
programmed in the proper way to take advantage of that potential.
 
And the problem with traditional OOP is that, because of what kind of code
it produces, how data ends up being distributed in RAM and how it's being
accessed, it results in much less efficient code than it could be, if
data were being accessed in a more CPU-efficient manner.
 
This is the reason why eg. many game engines are moving away from
traditional OOP (which has been a staple of game engine design for many
decades) and towards a more DOD approach. Game engines benefit when the
CPU can do as much computation in each refresh cycle as possible, and
these computations tend to be of the type of number-crunching that deals
with enormous amounts of data, which benefits greatly from DOD.
 
This is not just some "artificial benchmark" that doesn't reflect
real-world applications. This is precisely an example of a real-world
application, being used (a lot!) out there, which greatly benefits from
a different approach at how the program is designed.
 
>>so they were implemented in their own compilation unit (which caused an
>>actual function call to be done when calling either one).
 
> LTO generally solves that problem.
 
LTO might help a bit in the future. It isn't very useful now, because
compilers have no implementation of it. People want the benefits now,
not some time in the future maybe perhaps, if the program is recompiled.
"Christian Hanné" <the.hanne@gmail.com>: Sep 16 12:25PM +0200

> LTO generally solves that problem.
 
There's a new LTO-version with 18TB per cartridge.
This will solve the problem for sure.
"Öö Tiib" <ootiib@hot.ee>: Sep 16 04:38AM -0700

On Wednesday, 16 September 2020 13:01:34 UTC+3, Juha Nieminen wrote:
 
> LTO might help a bit in the future. It isn't very useful now, because
> compilers have no implementation of it. People want the benefits now,
> not some time in the future maybe perhaps, if the program is recompiled.
 
Are you talking about Linear-Tape-Open or Link-Time-Optimisation?
"Christian Hanné" <the.hanne@gmail.com>: Sep 16 01:42PM +0200

>> compilers have no implementation of it. People want the benefits now,
>> not some time in the future maybe perhaps, if the program is recompiled.
 
> Are you talking about Linear-Tape-Open or Link-Time-Optimisation?
 
Of course about the first.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 15 09:53PM -0700

On 9/14/2020 2:38 AM, David Brown wrote:
 
> It is common to disable exceptions (and RTTI) in such low-level C++
> code, but I don't see it as an absolute requirement. It depends on the
> kind of OS you are writing.
 
Imvvvho, the a compiler becomes part of the process wrt compiling a
Kernel. Like POSIX. The compiler must respect the process/rules!
 
 
 
David Brown <david.brown@hesbynett.no>: Sep 16 10:17AM +0200

On 16/09/2020 06:53, Chris M. Thomasson wrote:
>> kind of OS you are writing.
 
> Imvvvho, the a compiler becomes part of the process wrt compiling a
> Kernel. Like POSIX. The compiler must respect the process/rules!
 
Some code (in C or C++) is written in a completely portable manner,
relying only on behaviour specified in the standards. But most is
dependent on implementation-specific behaviour at some point - and then
the compiler (and options) becomes part of the semantics and correctness
of the program. Sometimes code is still widely portable, and will work
as expected with a range of compilers, options, targets, etc. POSIX
codifies some behaviour as an additional standard, making it easier to
write code that is portable across a range of systems and compilers.
But lower-level code will often be more specific, and only work with a
tighter range of compilers and options.
 
So yes, the compiler is definitely part of the process for compiling a
kernel. The kernel code will have specific requirements for the
compiler used (such as particular extensions, or particular treatment of
certain things that are undefined in the standard, or particular
implementation-specific behaviour).
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)