5

I'm currently writing a wrapper for an std::stringstream and i want to forward all the operator<< calls through my class to the std::stringstream. This works just fine now (thanks to this question: wrapper class for STL stream: forward operator<< calls), but there is still one issue with it.

Let's say I have the following code:

class StreamWrapper {
private:
    std::stringstream buffer;
public:
    template<typename T>
    void write(T &t);

    template<typename T>
    friend StreamWrapper& operator<<(StreamWrapper& o, T const& t);

    // other stuff ...
};


template<typename T>
StreamWrapper& operator<<(StreamWrapper& o, T const& t) {
    o.write(t);
    return o;
}

template<typename T>
void StreamWrapper::write(T& t) {
    // other stuff ...

    buffer << t;

    // other stuff ...
}

If I now do this:

StreamWrapper wrapper;
wrapper << "text" << 15 << "stuff";

This works just fine. But if I want to use the stream modifiers like std::endl, which is a function according to http://www.cplusplus.com/reference/ios/endl, I simply doesn't compile.

StreamWrapper wrapper;
wrapper << "text" << 15 << "stuff" << std::endl;

Why? How can I forward the stream modifiers too?

Community
  • 1
  • 1
MarcDefiant
  • 6,649
  • 6
  • 29
  • 49
  • What's the compile error? – Grimm The Opiner Feb 12 '13 at 09:59
  • There are overloads of `operator<<` that take a function, and then call that function on the stream: http://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt http://en.cppreference.com/w/cpp/io/manip – BoBTFish Feb 12 '13 at 10:00

2 Answers2

3

See this answer.

You'll want 

typedef std::ostream& (*STRFUNC)(std::ostream&);

StreamWrapper& operator<<(STRFUNC func)  // as a member, othewise you need the additional StreamWrappe& argument first
{
  this->write(func);
  return *this;
}
Community
  • 1
  • 1
rubenvb
  • 74,642
  • 33
  • 187
  • 332
2

You seem to be doing a bit of extra work. I normally use:

class StreamWrapper
{
    // ...
public:
    template <typename T>
    StreamWrapper& operator<<( T const& obj )
    {
        //  ...
    }
};

With a modern compiler, this should work for all concrete types. The problem is that manipulators are template functions, so the compiler is unable to do template argument type deduction. The solution is to provide non-template overloads for the types of the manipulators:

StreamWrapper& operator<<( std::ostream& (*pf)( std::ostream& ) )
{
    //  For manipulators...
}

StreamWrapper& operator<<( std::basic_ios<char>& (*pf)( std::basic_ios<char>& )
{
    //  For manipulators...
}

Type deduction will fail for the manipulators, but the compiler will pick up these for function overload resolution.

(Note that you might need even more, for things like std::setw(int).)

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • Does the perfect forwarding idiom alleviate the problem if you have r-value reference support? – Tim Seguine Oct 18 '13 at 17:23
  • @Tim I don't think so. I don't see off hand how it would change anything. According to Scott Meyer (who I definitely trust), template names can't be perfect-forwarded (and I don't see how you could implement it in a compiler), and the manipulators are all template names. – James Kanze Oct 18 '13 at 17:54
  • If he said that, then I trust it too. I only had in my memory his repeated statements that universal references "bind to everything". – Tim Seguine Oct 18 '13 at 18:13
  • @Tim They bind to everything in the sense that none of the lvalue-ness aspects enter into consideration. They obviously don't bind to "everything" in the absolute sense; they can't bind to a totally unrelated type. The problem here is that the compiler cannot deduce the type to determine whether it is reference compatible or not. – James Kanze Oct 20 '13 at 10:11
  • Yes, that's clear now. There is no way to deduce the template arguments without a specific overload to help the compiler. – Tim Seguine Oct 21 '13 at 12:01