From: igodard@pacbell.net   
      
   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.   
   >   
   > What do you mean by "declared" in this context? I'm asking, because   
   > an immediately defining friend function definition within A::B::C would   
   > provide this feature.   
   Interesting - the compiler accepts immediate definition but not deferred   
   definition - see below   
   >   
   >> Is there any way to write an i/o operator for a nested class other than   
   >> making the whole nest public?   
   >   
   > Why doesn't this work for you:   
   >   
   > #include    
   >   
   > class A {   
   > private:   
   > class B;   
   > };   
   >   
   > class A::B {   
   > public:   
   > class C {   
   > friend std::ostream& operator<<(std::ostream& os, const C& c)   
   > {   
   > // Output something   
   > return os;   
   > }   
   > };   
   > };   
   Yes, that compiles, but this doesn't:   
   #include    
      
   class A {   
   private:   
   class B;   
   };   
      
   class A::B {   
   public:   
   class C {   
   friend std::ostream& operator<<(std::ostream& os, const C& c);   
   };   
   };   
      
   std::ostream& operator<<(std::ostream& os, const C& c)   
   {   
   // Output something   
   return os;   
   }   
      
   Please forgive my ignorance of the language, but I had thought that   
   immediate and deferred definition had identical semantics and differed   
   only in convenience and the ability to handle mutual recursion.   
      
   I don't care for the use of an immediate definition here - it puts   
   executable code in a .hh file, which I consider poor practice, but at   
   least it's a workaround for my use case.   
      
   But I don't think that immediate definition makes the problem go away in   
   general: if the intended friend was not a single function but a mutually   
   recursive pair then you are again stuck. Immediate definition is   
   impossible because of the recursion, and deferred definition complains   
   (as in my example) that A::B is private.   
      
   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?   
      
      
   --   
         [ 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)