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,068 of 33,346    |
|    Ivan Godard to All    |
|    Re: i/o of nested classes - impossible?    |
|    29 Mar 12 21:15:04    |
   
   From: igodard@pacbell.net   
      
   On 3/28/2012 9:41 PM, Daniel Krügler wrote:   
   > Am 28.03.2012 21:10, schrieb Ivan Godard:   
   >> On 3/26/2012 12:48 AM, Daniel Krügler wrote:   
   >>> On 2012-03-26 06:34, Ivan Godard wrote:   
   >>>> Given:   
   >>>> class A { private class B; ... };   
   >>>> class A::B { public class C {...}; };   
   >>>> std::ostream& operator<<(std::ostream&, const A::B::C&) {}   
   >>>> There seems to be no combination of "friend" or other cleverness   
   >>>> that will let the operator<< be declared.   
      
   >   
   >> A more general question: isn't the header of any definition   
   >> supposed to see exactly the same things that the corresponding   
   >> declaration could see? In my example, the compiler does not   
   >> complain on the declaration using A::B; why should it complain when   
   >> it sees A::B on the matching deferred definition?   
   >   
   > These are different, because the separate definition is now in a   
   > scope where the access to A::B is relevant. This is not needed   
   > within C itself.   
      
   I think I see: the definition cannot know that it corresponds to the   
   friend declaration until the definition header has been resolved, and   
   it cannot resolve the header until it knows what A::B::C means, and   
   that requires access to A::B.   
      
   However, this seems to be semantic-order order dependent: apparently   
   the language requires that each name in the declaration have access on   
   the fly as it parses the header. If instead it ignored access control   
   until after it had figured out which operator<< was being defined, and   
   only then looked to see if the located definition had access, then it   
   would pick up that the declaration and the definition were the same   
   and could use the access rights of the declaration for permissions of   
   the definition. I suppose doing it the way they did it precludes   
   picking up irrelevant (and eventually inaccessible) overloads during   
   resolution, so random code is more likely to find the right thing than   
   if it were done as I expected. Only the rare oddity, like mine, gets   
   "you can't get there from here".   
      
   Thank you.   
      
      
   --   
    [ 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