From: fmatthew5876@googlemail.com   
      
   On Tuesday, December 18, 2012 9:27:35 AM UTC-5, Daniel Krügler wrote:   
   > On 2012-12-18 01:29, fmatthew5876 wrote:   
   >   
   > > On Monday, December 17, 2012 2:48:44 PM UTC-5, Jeff Flinn wrote:   
   >   
   > >> My understanding is no. Google discriminated unions.   
      
   Lets try to prove for a simple case that we can read and write   
   two different union members interchangably.   
      
   Consider the following:   
      
   template    
   struct vec2 {   
   union {   
   T m[2];   
   struct {   
   T x;   
   T y;   
   };   
   };   
      
   We know that &m[0] == &x. In other words the address of of the array   
   of T m and the T x are the same. What about &m[1] and &y? m[1] and y   
   have the same type, namely T. If we can show that &m[1] == &y, then   
   we can safely read and write m[1] and y interchangeably.   
      
   We can prove that &m[1] == &y by proving that   
   (&m[1] - &m[0]) == (&y - &x).   
      
   First, lets consider (&m[1] - &m[0]). This quantity is required   
   to be sizeof(T). The standard mandates that the size of all   
   objects be large enough so that they can be stored in an array   
   so that alignment constraints are satisfied without any *external*   
   padding. Without this hard requirement, simple pointer arithmetic   
   would no longer work.   
      
   How about (&y - &x)? First, we cannot have (&y - &x) < sizeof(T).   
   \If we did, then part of x would overlap with y, which is   
   prohibited. Can we have (&y - &x) > sizeof(T)?   
      
   Assume (&y - &x) > sizeof(T), then the compiler must have inserted   
   some padding between x and y.   
      
   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.   
   Therefore, (&y - &x) is not > sizeof(T), we also showed (&y-&x)   
   is not < sizeof(T).   
   Therefore, (&y - &x) = sizeof(T) = (&m[1] - &m[0]).   
   Since &m[0] == &x, (&y - &x) = (&m[1] - &x)   
   which implies &y = &m[1].   
   and finally since y and m[1] have the same address and same   
   type, they can be read and written from interchangeably.   
      
      
   Please go ahead and destroy my proof. Lets figure this out.   
      
   (Either way this exercise is entirely academic, no sane   
   compiler is going to add extra padding between 2 struct   
   members of the same type).   
      
      
   --   
         [ 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)