From: thor@math.tu-berlin.de   
      
   If a class inheriting is a member of a same name from two distinct   
   bases, as in the following example:   
      
   struct  A {   
      int a;   
      
      A()   
        : a(1)   
      { }   
   };   
      
   struct B {   
      int a;   
      
      B()   
        : a(1)   
      { }   
   };   
      
   struct C : public A,B {   
      
      int getA()   
      {   
        return a;   
      }   
   };   
      
   int main(int argc,char **argv)   
   {   
      struct C c;   
      
      return c.getA();   
   }   
      
   the compiler clearly refuses the code on the basis that C::a could be   
   either A::a or B::a. Somehow, I had the expectation that inserting a   
      
   struct C : public A,B {   
      using A::a;  // <---   
      int getA()   
      {   
        return a;   
      }   
   };   
      
   should resolve this ambiguity, as it expresses what I would prefer to   
   do, but apparently, this is not the case. In this very harmless example,   
   replacing a by A::a in the getA() method would do, but in my real-life   
   example the number of required changes is a bit too large to make this a   
   convenient approach. The class layout found above (approximately) was   
   the outcome of a necessary refactoring of other code parts and the need   
   of the two (instead of one) base classes having access to the same   
   identical data.   
      
   My questions:   
      
   *) What is the rationale of not allowing the "using" directive to   
   resolve the ambiguity? It seems rather straight forward for me, but I   
   believe the compiler is correct here and it is a language design issue.   
   I would prefer to understand why the language does not make use of this   
   simple alternative.   
      
   *) Which other options do I have in this specific case? Note that in my   
   case I can even ensure that the values of the two "a" are constant and   
   identical throughout the life time of the classes, though I'm also happy   
   to discuss this issue in cases where this does not hold. virtual   
   inheritance where I move A::a into a common virtually derived base class   
   comes to my mind - any other options?   
      
   Thanks,   
   	Thomas   
      
      
   --   
         [ 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)