From: gelists@googlemail.com   
      
   On 2013-01-12 13:03:02, in comp.lang.c++.moderated fmatthew5876 wrote:   
      
   > On Tuesday, December 18, 2012 9:27:35 AM UTC-5, Daniel Krügler wrote:   
   >   
   > Lets try to prove for a simple case that we can read and write   
   > two different union members interchangably.   
      
   AIUI, proving that the addresses are the same doesn't prove that we can   
   read and write interchangeably. Couldn't it be that the compiler assumes   
   (based on the standard) that this is not possible and uses some   
   optimizations that only work if the assumption is correct?   
      
   IMO, what you're trying to prove here is that a struct with multiple   
   members of the same type has the same size (and therefore alignment) as   
   an array. That's something quite different than what you state in this   
   phrase.   
      
      
   > Here is a quote from 9.2.14 of the C++11 standard.   
   > "Nonstatic data members of a (non-union) class with the same   
   > access control (Clause 11) are allocated so that later   
   > members have higher addresses within a class object. The   
   > order of allocation of non-static data members with   
   > different access control is unspecified (11). Implementation   
   > alignment requirements might cause two adjacent members not   
   > to be allocated immediately after each other; so might   
   > requirements for space for managing virtual functions   
   > (10.3) and virtual base classes (10.1)."   
   >   
   > This paragragh states two possible reasons for a class/struct   
   > to pad elements. The first is for managing virtual functions.   
   > vec2 has no virtual functions so the compiler cannot add padding   
   > for this reason. The only other reason the compiler is allowed   
   > to add padding is for "implementation alignment requirements."   
   >   
   > Are there any implementation alignment requirements that may   
   > require padding between y and x of type T? The answer is no   
   > because if there were, you could not create an array of type T.   
   >   
   > The standard does not say the compiler is free to add padding   
   > for any reason it wants. Only for virtual and alignment, which   
   > we showed do not apply here.   
   >   
   > Therefore, the compiler cannot add padding between y and x.   
      
   I'm not sure you interpreted "implementation alignment requirements"   
   correctly. This is not a black/white question; there are degrees of   
   requirements: there are possible alignments, and there are optimal   
   alignments.   
      
   Couldn't it be that aligning the objects as required by an array is   
   suboptimal, and in the array the compiler aligns them suboptimally   
   because that is required by the standard, but follows the "alignment   
   requirements" for optimal alignment of the given platform for the struct   
   case (because it can, according to the standard, in the way I understand   
   this)?   
      
   Gerhard   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)