home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,280 of 33,346   
   Francis Glassborow to Joshua Maurice   
   Re: Trivial initialization after non-tri   
   11 May 12 03:20:55   
   
   5af765a3   
   From: francis.glassborow@btinternet.com   
      
   On 11/05/2012 00:23, Joshua Maurice wrote:   
   >   
   > This plays havoc with the analysis. Specifically, consider a slightly   
   > different program:   
   >      /* C code */   
   >      #include   
   >      typedef struct T1 { int x; int y; } T1;   
   >      typedef struct T2 { int x; int y; } T2;   
   >      int main(void)   
   >      {   
   >          void* p = malloc(sizeof(T1) + sizeof(T2));   
   >          T1 * t1 = p;   
   >          T2 * t2 = p;   
   >          t1->x = 1;   
   >          t2->y = 2;   
   >          return t1->x;   
   >      }   
   > Is that UB? I don't even know. It gets harder as we go on.   
   >   
   > This is definitely a C problem which was inherited by C++. With non-C   
   > types, specifically the ones with non-trivial constructors and non-   
   > trivial destructors, I think the rules are far clearer.   
   >   
   >   
      
   I agree that the status of such code is difficult to determine, C had   
   good reasons (well at least reasons) for its rule about access to a   
   common set of members. At least in part that goes back to C's need for   
   compatible types because struct type names do not have static linkage.   
   By contrast C++ struct/class names do have static linkage and that means   
   that reuse of a name with a different definition in another compilation   
   unit is ill-formed but no diagnostic is required.   
      
      
   C++ does not have the concept of compatible types. Even if some reading   
   of the c++ Standard makes the above defined behaviour I am 100% certain   
   that that should not be the case.   
      
   However regardless of the actual requirements of the Standard, any   
   programmer who writes code relying on the above having well-defined   
   behaviour is dangerously incompetent, not least because it would produce   
   a maintenance nightmare (which the C concept of compatible types already   
   creates in C)   
      
   Francis   
      
      
   --   
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca