Tuesday, November 26, 2019

Digest for comp.lang.c++@googlegroups.com - 7 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Nov 26 04:53PM +0100

Can anyone here tell me whether I have to enable the standard
macro __cplusplus to report the correct value with VC++ through
the /Zc:__cplusplus option of the compiler. If I don't the compiler
statically reports 199711L.
guinness.tony@gmail.com: Nov 26 08:29AM -0800

On Tuesday, 26 November 2019 15:53:57 UTC, Bonita Montero wrote:
> macro __cplusplus to report the correct value with VC++ through
> the /Zc:__cplusplus option of the compiler. If I don't the compiler
> statically reports 199711L.
 
Yes - right now, you do. "Explanation" here:
 
https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/
Barry Schwarz <schwarzb@delq.com>: Nov 26 03:23PM -0800

On Tue, 26 Nov 2019 16:53:48 +0100, Bonita Montero
>macro __cplusplus to report the correct value with VC++ through
>the /Zc:__cplusplus option of the compiler. If I don't the compiler
>statically reports 199711L.
 
Wouldn't that depend on which compiler you are using?
 
--
Remove del for email
David Brown <david.brown@hesbynett.no>: Nov 26 08:22AM +0100

On 25/11/2019 19:18, James Kuyper wrote:
 
> Therefore, implementations have the freedom to reorder class members
> only if you explicitly give them that freedom by using access control
> specifiers.
 
Just to add a touch of confusion here - implementations can reorder
class or struct members any way they want, as long as it is invisible to
the code. gcc had an optimisation that did this for a while,
re-arranging structs for better packing or more efficient access in
code. But it could only do that for very "local" structs - nothing that
was passed around much, or where the layout could conceivably have been
visible or dictated by external requirements. It was removed before
long, however, because it was rarely possible for the compiler to make
such re-arrangements safely and the code was complicated to maintain.
(It is just another example of the "as if" rule - compilers can do what
they want with the code, as long as it works "as if" it had followed all
the rules slavishly.) Needless to say, this re-arranging would not have
occurred for the kind of code under discussion in this thread, since the
order matters here.
 
>> members will be initializated in a different order than
>> declared.
 
> That could happen through the use of access control specifiers.
 
I don't think that is it. The "-Wreorder" warning in gcc, enabled by
"-Wall", gives you a warning if the order of initialisers does not match
the order of the members:
 
struct A {
int i;
int j;
A(): j (0), i (1) { }
};
 
That is because the compiler will actually initialise "i" first, then
"j" (I think the standards say this ordering is unspecified), and it
warns you that the order does not match what you wrote in the code.
Paavo Helde <myfirstname@osa.pri.ee>: Nov 26 10:19AM +0200

On 26.11.2019 9:22, David Brown wrote:
 
> That is because the compiler will actually initialise "i" first, then
> "j" (I think the standards say this ordering is unspecified), and it
> warns you that the order does not match what you wrote in the code.
 
The standard specifies the order of initialization very strictly:
 
"non-static data members are initialized in the order they were declared
in the class definition ([...] regardless of the order of the
mem-initializers)"
 
and even gives the reason for this order:
 
"[ Note: The declaration order is mandated to ensure that base and
member subobjects are destroyed in the reverse order of initialization.
—end note ]"
David Brown <david.brown@hesbynett.no>: Nov 26 10:15AM +0100

On 26/11/2019 09:19, Paavo Helde wrote:
 
> "[ Note: The declaration order is mandated to ensure that base and
> member subobjects are destroyed in the reverse order of initialization.
> —end note ]"
 
Thanks for that correction.
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 26 11:59AM -0500

On 11/26/19 2:22 AM, David Brown wrote:
 
> I don't think that is it. The "-Wreorder" warning in gcc, enabled by
> "-Wall", gives you a warning if the order of initialisers does not match
> the order of the members:
 
Yes, that was a mistake on my part. I assumed that his comment was
relevant to the previous discussion, and therefore was referring to a
warning about the order of allocation differing from the order of
declaration. There's a big difference between "allocation" and
"initialization", and I should have noticed it.
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)