7c89f4c0   
   From: francis.glassborow@btinternet.com   
      
   On 11/05/2012 22:30, Joshua Maurice wrote:   
   > On May 11, 3:20 am, Francis Glassborow   
   >   wrote:   
   >> 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.   
   >   
   > I thought the rule to allow reading and writing of the common   
   > leading members was done mostly to implement a "poor man's"   
   > inheritance. This is not true?   
   >   
   > Also, what do you mean by "static linkage"? Checking my random draft   
   > copy of the C standard and C++03, I see that the linkage types in   
   > both C and C++ are "external", "internal", and "none". In C, "6.2.2   
   > Linkages of identifiers / 6" says that struct tag identifiers have   
   > no linkage. In C++03, "3.5 Program and linkage / 4" says: "A name   
   > having namespace scope has external linkage if it is the name of   
   > [...] a named class (clause 9)". Offhand, if I were to hear "static   
   > linkage", I would assume one of "internal" or "none". However, what   
   > you said only makes sense if you meant "external linkage" when you   
   > said "static linkage". Right?   
      
   Yes, sorry, I was tired at the time and did not recall the correct   
   term.   
      
   Yes, C's leading member rule is to support 'poor man's inheritance'   
   but the basic problem is that a struct name in C has internal linkage   
   and so they had to introduce the concept of compatible types to allow   
   a type to be used in more than one TU.  I sometimes wish that the C   
   enthusiasts would recognise how badly compromised their type system   
   is. This is a serious problem when we try to maintain compatibility   
   between C and C++.  Look at some of the contortions needed to support   
   complex. In C it has to be a fundamental type, C++ not only has no   
   need for that but is better (IMO) by having it as a library 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)