Ostream Chaining, Output Order

ostream chaining, output order

The behavior of your code is unspecified as per the C++ Standard.

Explanation

The following (I removed std::endl for simplicity)

std::cout << "Hello, world!" << print( std::cout ); 

is equivalent to this:

operator<<(operator<<(std::cout, "Hello, World!"), print(std::cout));

which is a function call, passing two arguments:

• First argument is : operator<<(std::cout, "Hello, World!")
• Second argument is : print(std::cout)

Now, the Standard doesn't specify the order in which arguments are evaluated. It is unspecified. But your compiler seems to evaluate the second argument first, that is why it prints "How are you?" first, evaluating the second argument to a value of type std::ostream& which then gets passed to the call shown above (that value is the object std::cout itself).

Why hexadecimal output?

You get hexadecimal output because the second argument evaluates to std::cout, which is being printed as hexadecimal number, because std::cout implicitly converts into pointer value of void* type, which is why it is printed as hexadecimal number.

Try this:

void const *pointer = std::cout; //implicitly converts into pointer type!
std::cout << std::cout << std::endl;
std::cout << pointer << std::endl;

It will print the same value for both. For example, this example at ideone prints this:

0x804a044
0x804a044 

Also note that I didn't use explicit cast; rather std::cout is implicitly converted into pointer type.

Hope that helps.

---

What is the proper way to write a function that inserts data into an ostream but that can also chain with operator<<?

When it depends on what you mean by chaining? Obviously, the following wouldn't work (as explained above):

std::cout << X << print(std::cout) << Y << Z; //unspecified behaviour!

No matter how you write print().

However this is well-defined:

print(std::cout) << X << Y << Z; //well-defined behaviour!

Need to make context available to C++ ostream insertion operators

Write a custom stream manipulator that stores a reference to ddb using the iword/pword mechanism. Here is an example, you'd need to add locking around the iwork_indexes map in a multithreaded program.

class dbb
{
public:
    explicit dbb(int value) : m_value(value) {}
    int value() const { return m_value; }
private:
    int m_value;
};

class dbb_reliant_type
{
public:
    dbb_reliant_type(const std::string& value) : m_value(value) {}
    const std::string& value() const { return m_value; }
private:
    std::string m_value;
};

typedef std::map<std::ostream*, int> iword_map;
iword_map iword_indexes;

inline int get_iword_index(std::ostream& os)
{
    iword_map::const_iterator index = iword_indexes.find(&os);

    if(index == iword_indexes.end())
    {
        std::pair<iword_map::iterator, bool> inserted = iword_indexes.insert(std::make_pair(&os, os.xalloc()));
        index = inserted.first;
    }

    return index->second;
}

inline std::ostream& operator<<(std::ostream& os, const dbb& value)
{
    const int index = get_iword_index(os);

    if(os.pword(index) == 0)
        os.pword(index) = &const_cast<dbb&>(value);

    return os;
}

std::ostream& operator<<(std::ostream& os, const dbb_reliant_type& value)
{
    const int index = get_iword_index(os);
    dbb* deebeebee = reinterpret_cast<dbb*>(os.pword(index));
    os << value.value() << "(" << deebeebee->value() << ")";
    return os;
}

int main(int, char**)
{
    dbb deebeebee(5);
    dbb_reliant_type variable("blah");
    std::cout << deebeebee << variable << std::endl;
    return 0;
}

Function that prints something to std::ostream and returns std::ostream?

You can't fix the function. Nothing in the spec requires a compiler to evaluate a function call in an expression in any particular order with respect to some unrelated operator in the same expression. So without changing the calling code, you can't make MyPrint() evaluate after std::cout << "Value: "

Left-to-right order is mandated for expressions consisting of multiple consecutive << operators, so that will work. The point of operator<< returning the stream is that when operators are chained, the LHS of each one is supplied by the evaluation of the operator to its left.

You can't achieve the same thing with free function calls because they don't have a LHS. MyPrint() returns an object equal to std::cout, and so does std::cout << "Value: ", so you're effectively doing std::cout << std::cout, which is printing that hex value.

Since the desired output is:

Value: 12

the "right" thing to do is indeed to override operator<<. This frequently means you need to either make it a friend, or do this:

class WhateverItIsYouReallyWantToPrint {
    public:
    void print(ostream &out) const {
        // do whatever
    }
};

ostream &operator<<(ostream &out, const WhateverItIsYouReallyWantToPrint &obj) {
    obj.print(out);
}

If overriding operator<< for your class isn't appropriate, for example because there are multiple formats that you might want to print, and you want to write a different function for each one, then you should either give up on the idea of operator chaining and just call the function, or else write multiple classes that take your object as a constructor parameter, each with different operator overloads.

Why we need to return reference to istream/ostream while overloading and operators?

The reason is a combination of several facts.

1. You want to be able to chain input and output operations as in

   in  >> x >> y;
   
   out << z << std::precision(10) << t << std::endl;
   

   so you must return something that allows operator<< again.

2. Since you want your operator to work on any istream, i.e. any object derived from std::istream, you cannot define

   operator<<(istream_type, object);    // take istream by value
   

   since this would only work for the specific istream type istream_type, but not for a generic istream. For that one must use polymorphism, i.e. either take a reference or a pointer (which will be a reference or pointer to a class derived from std::istream).

3. Since you only have a reference to the istream, you cannot return the istream object itself (which may be of a type not even defined at the point of the definition of operator<<) but only the reference you've got.

   One could get around this restriction by defining operator<< a template and take and return the istream_type by value, but that requires the istream type to have a copy constructor, which it may well not have for good reasons.

4. In order to envoke polymorphism one could, in principle, use pointers (to streams) rather than references. However, operator<<(stream*,const char*) is
   not allowed in C++ (at least one operand must be of class or enumeration type).

   Thus, with stream pointers one must use function-call syntax and you're back with C-style fprintf(stream*, args...).

   Moreover, pointers can be null or dangling, which in fact is their default state (when declared without initializer), while a reference can be assumed to be valid (it cannot be declared without initializer).

Is it possible to tie a C++ output stream to another output stream?

Yes, you can:

out1.tie( & out2 );

where both outs are output streams. out2 will be flushed before output to out1.

Order of evaluation of arguments using std::cout

The evaluation order of elements in an expression is unspecified (except some very particular cases, such as the && and || operators and the ternary operator, which introduce sequence points); so, it's not guaranteed that test will be evaluated before or after foo(test) (which modifies it).

If your code relies on a particular order of evaluation the simplest method to obtain it is to split your expression in several separated statements.

---

Related Topics