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, butoperator<<takes an lvalue as first argument -
operator<<returns anostream&(well, at least for the standard ones actually abasic_ostream<CharT, Traits>&whereCharTandTraitsare 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:
-
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::forwardcorrect here? -
Is there an easier way to meet the requirements?
-
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)?
There’s a generic inserter to take rvalue streams, but it returns a
basic_ostream<charT, traits>&:To work correctly for your example it would have to return the derived type of the stream (
std::ostringstram).Your code looks correct to me.
Your code looks similar to the code I wrote to solve this problem (see below).
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:
Unlike yours, this only accepts rvalue streams. But like yours, it returns the concrete derived type, and so works with your example.