Thread: C++ method lookup

Umm so I ran into this weird problem today.
It's probably my own ignorance but I wanted to know why this happens
and if it's supposed to.

Say I have this code:
(Using MinGW/GCC 4.5 compiler on Windows)

Code:

class Bar
{
protected:

    // ctor/dtor

    ssize_t Write(const void* buffer, size_t bytes);
};

class Foo : public Bar
{
public:

    // ctors etc.

    // ...

    void Write(int8_t value);
};


void Foo::Write(int8_t value)
{
    // UH OH
    // Compiler complains that there is no "matching function call to
    // Foo::Write(void*, unsinged int)"
    Write(&value, sizeof(value));
}

So what is going on here?

It appears that the compiler "knows" that there is a Write() method
that takes two arguments, but for some reason it can't look it up.

Now if I say:

Code:

void Foo::Write(int8_t value)
{
    Bar::Write(&value, sizeof(value));
}

that sort of works until we get to the link stage...

make Bar::Write virtual, and it should work

Originally Posted by Elkvis

make Bar::Write virtual, and it should work

Mind explaining why?
Because that doesn't make sense to me and when I tried it it didn't work.
Thanks for the reply though.

Aha! Thanks laserlight. I've got it working now.
Yeah I don't know why I was getting unresolved symbols.
I probably did something dumb with my build.

Thanks for the help.

I would also argue that this is a poor design. Changing the declaration of Write in a derived class makes the hierarchy difficult to understand and I don't recommend doing this. There is a much better way using interfaces and then allowing derived classes to implement the interface the way they need to but every derived object must adhere to the interface. This means that while Write() may write differently in derived classes it follows the same declaration and prototype in the interface.

I could also argue that if Foo needed a different Write() then perhaps a separate function should be provided in Bar for this very reason. However I'm not a big fan of overloaded functions because they can cause confusion when taken to the extreme. I prefer two separate functions with two distinct names. Note I said when taken to the extreme. In certain circumstances overloaded functions are fine. But again if you are programming to an interface instead of an implementation a lot of this confusion can be easily avoided.