Overly Strict Const Overloading

I've run into some strange linkage problems with gcc (and MSVC) with regards to finding an overloaded stream operator in a C++ library I created. The gist of it is very simple, I have a class called gpumat. This class overloads the << operator like this:

Code:

class gpumat {
/* stuff */

} ;

std::ostream& operator<<(std::ostream& output, const gpumat & p) // print a gpumat
{
/* implementation */
}

/* .....  usage */
using namespace std ;
gpumat g(3,4) ;
g.cgauss()
cout << g << endl ;

Note the const identifier before the &p input argument.
For gcc the linker will fail with something like:
undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, gpumat&)'.

This is baffling to me since it's perfectly legal to pass a non const. variable into a function that has a const specifier. The const is supposed to mean that the function will not change it's input. Moreover if I wanted to print a temporary computation, the const declaration is required as I understand it, ie:

Code:

gpumat a, b ;
/* initialization */
cout << a + b << endl ;

Microsoft's cl.exe will fail to link if you do not have the const specifier in front of &p if you pass a temporary class into the << operator (or any other overloaded function actually).

If I remove the const token gcc compiles links and runs my code just fine.

Code:

class gpumat {
/* stuff */

} ;

std::ostream& operator<<(std::ostream& output, gpumat & p) // print a gpumat
{
/* implementation */
}

/* .....  usage */
using namespace std ;
gpumat g(3,4) ;
g.cgauss()
cout << g << endl ;

How can this be correct? If it is one would have to supply const and non const versions of every overloaded function/operator for each argument and it would remove any optimization advantage since the non-constant version would be linked in for most usage patterns.

undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, gpumat&)'.

This should pretty much mean that you have declared it like that somewhere. Make sure declarations match definitions. Should be const everywhere.

Originally Posted by anon

This should pretty much mean that you have declared it like that somewhere. Make sure declarations match definitions. Should be const everywhere.

Interesting point actually. Unless I declared it twice (scrambling to double check), I did have the same declaration in both definition and implementation (I did). I suppose it would be too much to ask to get a compiler error instead of a link error if it were wrong.

This is gcc 4.4.1 that's doing this. In fact it should be a bug if I use the exact same declaration as the implementation, and it compiles correctly but does not link correctly.

That is if the use of the operator had no declaration that satisfies such use I would get a compiler error I would think, but if it does match then the object code linkage should match as well.

However I still want to know whether or not ANSI C++ should give me an error in my test case. Shouldn't I actually be able to link against code declared with const reference arguments?

The parameter should be const and then the code is correct.

But the linker error message says that somehow it got the idea there must be an overload with the non-const reference. It doesn't generally pull these ideas from the thin air. It must have been declared at the point where it is used.

May-be you'd need to rebuild the project (bad object files)?

So using gcc 4.4.1, g++ loves the following example:

Code:

#include <iostream>

class gpumat {
    private:
        int x, y;

    public:
        int getx() const;
        int gety() const;
        gpumat(int, int);
};

gpumat::gpumat(int x1, int y1) : x(x1), y(y1) { };

int gpumat::getx() const {
    return x;
}

int gpumat::gety() const {
    return y;
}

std::ostream& operator<< (std::ostream& output, const gpumat &p) {
    output << "(" << p.getx() << ", " << p.gety() << ")";
    return output;
}

using namespace std;
int main() {
    gpumat g(3,4);
    cout << g << endl;
}

So apparently there's something in the /* */ bits that is causing the issue. (I checked: leaving the const off the getx/gety functions gives a different error message:

Code:

seven.cpp:24: error: passing ‘const gpumat’ as ‘this’ argument of ‘int gpumat::getx()’ discards qualifiers

so that seems okay.)

interesting. You should post more code, the issue is probably somewhere else

Originally Posted by SevenThunders

Interesting point actually. Unless I declared it twice (scrambling to double check), I did have the same declaration in both definition and implementation (I did). I suppose it would be too much to ask to get a compiler error instead of a link error if it were wrong.

If, at the point where the operator is used, the compiler sees this;

Code:

std::ostream& operator<< (std::ostream& output, gpumat &p);  // look ma!!! no const

then your calling function will attempt to call the non-const version because g is non-const. If you have not implemented a non-const version, the linker detects that and complains.

Originally Posted by SevenThunders

This is gcc 4.4.1 that's doing this. In fact it should be a bug if I use the exact same declaration as the implementation, and it compiles correctly but does not link correctly.

Maybe. Despite the fact you are arguing the problem is with the compiler, there is about a 99.99% chance the problem is in your code rather than with the compiler and linker.

The two possibilities for what you are seeing are;

1) Your code, at the point where you use the operator, has provided a declaration of a non-const version of your operator. But you have only implemented the const version.

2) You have left the object file that contains the implementation of the operator out of the link.

The first is because you have lied to the compiler, the compiler has accepted your word, and the linker detects that you have lied.

The second is because the linker is required to only search through object files or libraries it is told to. If you do not supply a needed object file (i.e. one that contains a needed function) the linker rightfully complains about not finding that function.

Originally Posted by SevenThunders

That is if the use of the operator had no declaration that satisfies such use I would get a compiler error I would think, but if it does match then the object code linkage should match as well.

That is correct. The fact you are not getting such an error means you have such a function declared. The fact you are getting a linker error means that the linker is not able to find the function you declared to the compiler. As per the reasoning I gave above.

The problem is still in your code, not with the compiler. A compiler is an ignoramous that does what it does, regardless of what you expect it to do.

Originally Posted by SevenThunders

However I still want to know whether or not ANSI C++ should give me an error in my test case. Shouldn't I actually be able to link against code declared with const reference arguments?

If you've described your test case accurately, the ISO standard does not require a compiler error.

The compiler is certainly not required to complain if your code has declared a non-const version of the operator. When working with a non-const object (g in your code), the compiler is potentially able to call a non-const or a const version of the operator. If you have declared both, the ISO C++ standard requires that the non-const version be called and not the const version (the non-const version is a better match to the object). If you have declared only the non-const version that is the one which is required to be called.

Either way, if the non-const version is required to be called, then the compiler is not required to complain. The linker will, however, complain if it cannot find that function.

To find the erroneous declaration that has a non-const argument, comment out the const version of the operator overload, then try to stream a const object.

Code:

const gpumat cgm;
std::cout << cgm;

The compiler should emit an error about not being able to find a suitable overload, and hopefully also a note pointing the unsuitable candidate overload that takes the non-const argument.