C++ overloading

Question

The following code is giving me a compilation error. Can anyone please tell me why?

class mytype {
public:
    int value;
    mytype(int a) {
        value = a;
    }
    friend ostream& operator<<(ostream& stream, const mytype& a) {
        stream << a.value;//works
        return stream;
    }
    friend ostringstream& operator<<(ostringstream& stream, const mytype& a) {
        stream << (a.value);//compilation error
        return stream;
    }
};

Error:

error C2027: use of undefined type 'std::basic_ostringstream<_Elem,_Traits,_Alloc>'

Upon fixing that:

error C2666: 'operator <<' : 18 overloads have similar conversions

Final fix:

Declare constructor as explicit. Works on MSVC then.

I wonder why.

Answer 1

error C2027: use of undefined type 'std::basic_ostringstream<_Elem,_Traits,_Alloc>'

You need #include <sstream> to get the [i/o]stringstream classes.

About the other errors

The problem with an overload of the form

ostringstream& operator<<(ostringstream& stream, const mytype& a)

is that it matches an ostringstream exactly. Why is it a bad thing to have a more exact overload? From the standard, §13.3.3/1-2:

a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2) …

If there is exactly one viable function that is a better function than all other viable functions, then it is the one selected by overload resolution; otherwise the call is ill-formed

Therefore if operator<<( ostream &, int ) and operator<<( ostringstream &, mytype const & ) are both candidates for stream << value, the former matches int exactly with no conversion but the latter matches ostringstream exactly. Therefore neither can be "not worse" for all arguments, and neither candidate may be chosen.

But the code is valid because of a loophole. Your overload is not a candidate at all, except when you actually use your type in the function call. When you declare/define a friend inside a class block, it does not introduce it to any namespace scope; it merely associates it with the class scope, which allows it to be found if that class type describes one of the arguments being passed.

The standard has this to say about friend declarations, although it's in another section (14.6.5):

Friend declarations do not introduce new names into any scope…

So, MSVC tried to be nice and proactively introduced your friend to its enclosing namespace. Strike against MSVC.

However, when I attempted to add a declaration equivalent to what MSVC did "for free," Comeau and GCC nicely resolved the resulting overloading conflict — strike against them. Or is it? As it turns out, the overloaded call occurs earlier in the file than my recommended declaration. If I move the declaration before class mytype { (which requires forward-declaring mytype), then both properly complain about the ambiguity.

Using an overload before it is declared in namespace scope appears to be well and good according to §3.3-3.4 of the Standard. So actually GCC and Comeau were both in the right. The point of declaration is right after the name of the declared object. (And last I checked, self-referential function declarations can still crash GCC.) ADL invokes unqualified lookup into the enclosing namespace at a point immediately before the enclosing class. (3.4.1/8 final bullet, 3.4.1/9, 3.4.2/2a.) If the friend hasn't been declared before the class, it's legitimately not a candidate. (7.3.1.2/3) Isn't C++ a beautiful language?

How keep the simplified example on GCC, but break subsequent code.

    friend ostringstream& operator<<(ostringstream& stream, const mytype& a) {
        stream << (a.value);//compilation error
        return stream;
    }
};

ostringstream& operator<<(ostringstream& stream, const mytype& a); // <- here

Following this declaration, it will be impossible to write an int into an ostringstream.

How to break everything uniformly, with simpler declaration semantics.

class mytype; // <- here
              // and here:
inline ostringstream& operator<<(ostringstream& stream, const mytype& a);

class mytype {
public:

Following this declaration, it will be impossible to write an int into an ostringstream… including the friend declarations inside class mytype {}.

Actual solution.

The stream classes are supposed to be indistinguishable. If you really want to determine whether a given stream feeds a string in memory (and you shouldn't), it's best to look at its internal streambuf object, returned by rdbuf(), which actually performs the I/O gruntwork. Even a generic ostream object can have ostringstream functionality if given a stringbuf.

 if ( typeid( stream.rdbuf() ) == typeid( stringbuf * ) ) {
     // this is effectively a stringstream
 } else {
     // not a stringstream
 }

Answer 2

There is an overload ambiguity in the call to operator<< in the ostringstream overload.

stream << a.value;

There are a number of operator<< overloads that are members of the ostream class, which is a base class of ostringstream. One of these is declared as:

ostream& ostream::operator<<(int);

This overload is an exact match for the right-hand side (a.value is an int) but requires a derived-to-base conversion on the left-hand side (stream is an ostringstream, which is derived from ostream).

However, there is also your ostringstream overload:

ostringstream& operator<<(ostringstream&, const mytype&);

This overload is an exact match for the left-hand side (stream is an ostringstream), and a user-defined converting constructor (your mytype(int) constructor) can be used to convert a.value (an int) to a mytype.

Since one overload matches the first argument better and the other overload matches the second argument better, there is an ambiguity. You can fix this either by:

• Explicitly converting the left-hand side to an ostream (using (ostream&)stream = a.value;), or
• Remove the user-defined conversion by making the constructor explicit.