13

I'm thinking about a problem which has some similarity with perfect forwarding, but where the function argument is not passed to a called function, but returned. This is why I call it "perfect pass-through".

The problem is the following:

Say we have a function which takes an object by reference (and possibly some extra arguments), modifies that object, and returns the modified object. The best-known example of such functions are probably operator<< and operator>> for iostreams.

Let's use iostreams as example, because it allows to nicely show what I'm after. For example, one thing which one would sometimes like to do is:

std::string s = (std::ostringstream() << foo << bar << baz).str();

Of course that doesn't work, for two reasons:

  • std::ostringstream() is an rvalue, but operator<< takes an lvalue as first argument

  • operator<< returns an ostream& (well, at least for the standard ones actually a basic_ostream<CharT, Traits>& where CharT and Traits are deduced from the first argument).

So let's assume we want to design the insertion operator so that the above works (you obviously can't do that for the existing operators, but you can do that for your own classes). Obviously the solution should have the following traits:

  • The first argument can accept either an lvalue or an rvalue.

  • The return type should be the same type as passed in. But of course it should still only accept ostreams (i.e. classes derived from an instantiation of basic_ostream).

While in this specific use case it isn't needed, I want to add a third requirement:

  • If the first argument is an rvalue, so is the returned value, otherwise an lvalue is returned.

This extra rule is so that you can move-construct from an rvalue passed through the function (I don't know if C++11 streams are move constructible, but it is intended to be a more general scheme, with the stream just as handy example).

It is obvious that in C++03, those requirements could not all be met. However, in C++11, we have rvalue references, which should make this possible.

Here's my try on this:

#include <iostream>
#include <sstream>
#include <string>

template<typename Ostream> struct is_ostream
{
  typedef typename std::remove_reference<Ostream>::type candidate;
  typedef typename candidate::char_type char_type;
  typedef typename candidate::traits_type traits_type;
  typedef std::basic_ostream<char_type, traits_type> basic_ostream;
  static const bool value = std::is_base_of<basic_ostream, candidate>::value;
};

class SomeType {};

template<typename Ostream>
 typename std::enable_if<is_ostream<Ostream>::value, Ostream&&>::type
  operator<<(Ostream&& is, SomeType const& x)
{
  is << "SomeType";
  return std::forward<Ostream>(is);
}

int main()
{
  SomeType t;

  std::string s = (std::ostringstream() << t).str();

  std::cout << s << std::endl;
}

It indeed compiles with gcc (using the option -std=c++0x), and when run outputs SomeType as expected. However, it is a quite complicated machinery to get there.

Therefore my questions:

  1. Is the output operator as I wrote it indeed working as expected (and fulfilling all the requirements I gave)? Or could it fail in unexpected ways or have other unexpected consequences? Especially: Is my use of std::forward correct here?

  2. Is there an easier way to meet the requirements?

  3. Assuming this is indeed correct and the simplest way to do it: Do you consider it a good idea to do that, or would you advice against it (both specifically for stream output as in my example, and as a more general scheme for passing objects through functions)?

Bryan Chen
  • 45,816
  • 18
  • 112
  • 143
celtschk
  • 19,311
  • 3
  • 39
  • 64
  • "`std::ostringstream()` is an rvalue, but `operator<<` takes an lvalue as first argument" - in C++11, there is one overload for rvalues (`ostream& operator<<(ostream&& o, T const&)` template), that simply forwards to the lvalue version. Also, this "rvalue" problem only existed in C++03 for those `operator<<` overloads that were defined out-of-class. Also, `operator<<` returns an `ostream`, I edited that for you. Lastly, yes, C++11 streams are indeed movable. – Xeo Jan 11 '12 at 22:38
  • @Xeo: Thanks for the information. However, the rvalue overload still doesn't meet all my criteria: it still returns an `istream` instead of the exact class (i.e. I still wouldn't be able to call `str()` at the end), and (assuming you didn't just forget an `&`) it also removes the rvalueness (violating my third condition). – celtschk Jan 11 '12 at 22:50
  • You keep writing `istream` instead of `ostream`... :) And no, I didn't forget a `&`, it indeed discards the rvalueness. I only wanted to mention that such an overload exists, as such invalidating one of your problem points. – Xeo Jan 11 '12 at 23:38

1 Answers1

6

std::ostringstream() is an rvalue, but operator<< takes an lvalue as first argument

There's a generic inserter to take rvalue streams, but it returns a basic_ostream<charT, traits>&:

template <class charT, class traits, class T>
  basic_ostream<charT, traits>&
  operator<<(basic_ostream<charT, traits>&& os, const T& x);

To work correctly for your example it would have to return the derived type of the stream (std::ostringstram).

  1. Is the output operator as I wrote it indeed working as expected (and fulfilling all the requirements I gave)? Or could it fail in unexpected ways or have other unexpected consequences? Especially: Is my use of std::forward correct here?

Your code looks correct to me.

  1. Is there an easier way to meet the requirements?

Your code looks similar to the code I wrote to solve this problem (see below).

  1. Assuming this is indeed correct and the simplest way to do it: Do you consider it a good idea to do that, or would you advice against it (both specifically for stream output as in my example, and as a more general scheme for passing objects through functions)?

The idiom looks fine to me.

In libc++ I defined the rvalue ostream inserter like the following (as an extension). I made an attempt to get it standardized but it was late and the committee was understandably not in the mood for more thrashing:

template <class _Stream, class _Tp>
inline
typename enable_if
<
    !is_lvalue_reference<_Stream>::value &&
    is_base_of<ios_base, _Stream>::value,
    _Stream&&
>::type
operator<<(_Stream&& __os, const _Tp& __x)
{
    __os << __x;
    return std::move(__os);
}

Unlike yours, this only accepts rvalue streams. But like yours, it returns the concrete derived type, and so works with your example.

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • 4
    Thanks for your answer. BTW, I think there's a flaw with the interaction of your two decisions in your library: Since your rvalue version of `operator<<` returns an lvalue, chained `operator<<` calls will use the lvalue version. And since the lvalue version of `operator<<` does not preserve the exact type, I think your library will allow `(std::ostringstream() << foo).str()` but *not* `(std::ostringstream() << foo << bar).str()`. Which I'd consider a rather strange inconsistency. – celtschk Jan 11 '12 at 23:10
  • The [Howard's answer to this similar question](http://stackoverflow.com/a/8829047/201725) mentions it was discussed as [LWG 1203](http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203), but not accepted in the standard. – Jan Hudec Jul 23 '12 at 12:03
  • To fix the problem noted by @celtschk, change the type in the `enable_if` from `_Stream&` to `_Stream&&` and the return statement to `return move(__os)`. – metal Aug 07 '13 at 20:34
  • This needs to be in the std namespace, right -- meaning the std:: on move() is superfluous, and unless this sort of thing makes it into the standard, this code is a bit dodgy since the standard disallows us adding to std. Right? – metal Feb 25 '14 at 13:17
  • 1
    @metal: The `std::` on `move` disables ADL. We don't want to accidentally pick up some other `move`. And yes, this is the libc++ implementation (http://libcxx.llvm.org): an implementation of the std::lib. So it is in namespace std. – Howard Hinnant Feb 25 '14 at 15:40