From: francis.glassborow@btinternet.com   
      
   On 12/01/2013 19:03, fmatthew5876 wrote:   
   > 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.   
      
   But it notably does not state that these are the only reasons. It just   
   gives two common ones. So your argument fails.   
      
   BTW one reason compilers add padding is for purposes of debugging by   
   ensuring that distinct objects have space between them which allows   
   checking for writing one beyond the end of an array (and single objects   
   are arrays of one -- goes all the way back to C)   
      
      
   --   
         [ 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)