Overloading operator<<: cannot bind lvalue to ‘std::basic_ostream<char>&&’
Asked Answered
V

3

42

I have a class that uses a nested class, and want to use the nested class operator<< to define operator<< in the upper class. Here is how my code looks like:

#include <memory>
#include <iostream>

template<typename T>
struct classA {
  struct classB
  {
    template<typename U>
    friend inline std::ostream& operator<< (std::ostream &out,
                                            const typename classA<U>::classB &b);
  };

  classB root;

  template<typename U>
  friend std::ostream& operator<< (std::ostream &out,
                                   const classA<U> &tree);
};

template<typename T>
inline std::ostream& operator<< (std::ostream &out,
                                 const classA<T> &tree)
{
  out << tree.root;
  return out;
}

template<typename T>
inline std::ostream& operator<< (std::ostream &out,
                                 const typename classA<T>::classB &b)
{
  return out;
}

int main()
{
  classA<int> a;
  std::cout << a;
}
  • When compiling without support for C++11, the definition of operator<< for the inner class seems not to be found by the compiler:

    so.hpp:24:7: error: no match for ‘operator<<’ in ‘out << tree.classA<int>::root’
    so.hpp:24:7: note: candidates are: ...
    
  • With GCC 4.6 and 4.7 when compiling with std=c++0x:

    so.hpp:21:3: error: cannot bind ‘std::ostream {aka std::basic_ostream<char>}’ lvalue to ‘std::basic_ostream<char>&&’
    In file included from /usr/include/c++/4.7/iostream:40:0,
                     from so.hpp:2:
    /usr/include/c++/4.7/ostream:600:5: error:   initializing argument 1 of ‘std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = classA<int>::classB]’
    

Can someone tell me why this code is not legal, and what's the best way to do what I want?

Vonnievonny answered 18/5, 2012 at 10:44 Comment(0)
R
23

Bo provided the reason why this is happening (the type T is not deducible in the call to the nested operator<<. A simple workaround for this, and something that I recommend in general, not only here, is not befriending a template, but rather a single free function. For that you will need to define the function inline:

template<typename T>
struct classA {
  struct classB
  {
    friend inline std::ostream& operator<< (std::ostream &out,
                                            const classB &b) {
       // definition goes here
    }
  };

  classB root;

  friend std::ostream& operator<< (std::ostream &out,
                                   const classA<U> &tree) {
       // definition goes here
  }
};

There are a couple of differences among the two approaches. The most important one is that this approach will have the compiler define a non-templated overload for operator<< for each instantiation of the template, which because it is no longer a template, does not depend on deducing the arguments. Another side effects are that the approach is a little tighter (you are only befriending one function, while in your initial approach you befriended the template and all possible instantiations (which can be used as a loophole to gain access to your class internals). Finally the functions so defined will only be found through ADL, so there are less overloads of operator<< for the compiler to consider when the argument is not ClassA<T> or ClassA<T>::ClassB.


How access can be gained with your approach

namespace {
   struct intruder {
       ClassA & ref;
       intruder( ClassA& r ) : ref(r) {}
   };
   template <>
   std::ostream& operator<< <intruder>( std::ostream& _, ClassA<intruder> const& i ) {
       std::cout << i.ref.private_member << std::endl;
       return _;
   }
}

Alternative

Alternatively you can befriend a particular specialization of a template. That will solve the intruder problem, as it will only be open to operator<< to ClassA<intruder>, which has a much lesser impact. But this will not solve your particular issue, as the type would still not be deducible.

Revolving answered 18/5, 2012 at 11:49 Comment(4)
I see it like a better design rather than a workaround. It has it's downside (you cannot take the address of the friend function declared inside the template class), but on all other accounts it is a better fit to provide free function operators...Nassi
This is the Making New Friends idiom, so not really a workaround.Climb
@TBBle: It's good that someone found a name for it, but that idiom has been in use for a long time by no name and it is just fine :)Nassi
I wasn't meaning to imply that it stopped being a workaround once it was named. This name for the idiom is at least 10 years old. The changes that made it necessary are more than 10 years older than that though, as far as I can tell. Although at the time, the examples of this use-case all seemed to go with "pre-declare".Climb
V
29

You have a problem with a "non-deducible context" in this operator

template<typename T>
inline std::ostream& operator<< (std::ostream &out,
                                 const typename classA<T>::classB &b)
{
  return out;
}

The compiler cannot figure out what values of T will result in a classB that matches the parameter you want to pass. So this template is not considered!

In C++11 mode, the compiler then goes on to find a close match from the standard library

operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&)

where it can match _Tp to just about any type, including classA<T>::classB, but notes that the first parameter doesn't match.

Venezuela answered 18/5, 2012 at 11:24 Comment(2)
The comment about the close match made it clear why I was having a similar problem.Shaunda
Thanks for the link, it helped a lot to understand what are you talking aboutMycostatin
R
23

Bo provided the reason why this is happening (the type T is not deducible in the call to the nested operator<<. A simple workaround for this, and something that I recommend in general, not only here, is not befriending a template, but rather a single free function. For that you will need to define the function inline:

template<typename T>
struct classA {
  struct classB
  {
    friend inline std::ostream& operator<< (std::ostream &out,
                                            const classB &b) {
       // definition goes here
    }
  };

  classB root;

  friend std::ostream& operator<< (std::ostream &out,
                                   const classA<U> &tree) {
       // definition goes here
  }
};

There are a couple of differences among the two approaches. The most important one is that this approach will have the compiler define a non-templated overload for operator<< for each instantiation of the template, which because it is no longer a template, does not depend on deducing the arguments. Another side effects are that the approach is a little tighter (you are only befriending one function, while in your initial approach you befriended the template and all possible instantiations (which can be used as a loophole to gain access to your class internals). Finally the functions so defined will only be found through ADL, so there are less overloads of operator<< for the compiler to consider when the argument is not ClassA<T> or ClassA<T>::ClassB.


How access can be gained with your approach

namespace {
   struct intruder {
       ClassA & ref;
       intruder( ClassA& r ) : ref(r) {}
   };
   template <>
   std::ostream& operator<< <intruder>( std::ostream& _, ClassA<intruder> const& i ) {
       std::cout << i.ref.private_member << std::endl;
       return _;
   }
}

Alternative

Alternatively you can befriend a particular specialization of a template. That will solve the intruder problem, as it will only be open to operator<< to ClassA<intruder>, which has a much lesser impact. But this will not solve your particular issue, as the type would still not be deducible.

Revolving answered 18/5, 2012 at 11:49 Comment(4)
I see it like a better design rather than a workaround. It has it's downside (you cannot take the address of the friend function declared inside the template class), but on all other accounts it is a better fit to provide free function operators...Nassi
This is the Making New Friends idiom, so not really a workaround.Climb
@TBBle: It's good that someone found a name for it, but that idiom has been in use for a long time by no name and it is just fine :)Nassi
I wasn't meaning to imply that it stopped being a workaround once it was named. This name for the idiom is at least 10 years old. The changes that made it necessary are more than 10 years older than that though, as far as I can tell. Although at the time, the examples of this use-case all seemed to go with "pre-declare".Climb
S
2

Try this:

template<typename T>
inline std::ostream& operator<< (std::ostream &out,
                             const classA<T> &tree)
{
   //out << tree.root;
   ::operator<<( out, tree.root);
   return out;
}

and then you will get a straightforward confession of ineptitude:

test.cpp:34:3: error: no matching function for call to ‘operator<<(std::ostream&, const classA<int>::classB&)’
test.cpp:34:3: note: candidates are:
test.cpp:23:22: note: template<class T> std::ostream& operator<<(std::ostream&, const     typename classA<T>::classB&)
test.cpp:30:22: note: template<class T> std::ostream& operator<<(std::ostream&, const classA<T>&)

Workaround: maybe you can use a member function in nested classB, and use it instead of operator<< ... Of course, that solution has a multitude of drawbacks, but it may get you out of this hurry.

Santoyo answered 18/5, 2012 at 11:32 Comment(1)
You can always explicitly call ::operator<< <T> (out, tree.root) instead, but I think that named member functions now look more attractive.Icj

© 2022 - 2024 — McMap. All rights reserved.