non-virtual functions declared in class with virtual functions

[Yadrif]

What are the two non-virtual functions

bool operator ==(const DerivedFromSomeInterfaceIF& right) const
bool operator !=(const SomeInterfaceIF& rhs) const;

in SomeInterfaceIF class doing, if anything?

There is no cooresponding .cpp file with any implementation for them. I don't get what the purpose of these are since they are not marked as pure virtual and have no implementation. I get no compile errors.

#include <cstdlib>
#include <iostream>

using namespace std;

class SomeInterfaceIF
{
    public:
    
        virtual string getName() = 0;
        virtual string getValue() = 0;

        bool operator ==(const SomeInterfaceIF& rhs) const;
        bool operator !=(const SomeInterfaceIF& rhs) const; 

        virtual ~SomeInterfaceIF(){};
    
};

class DerivedFromSomeInterfaceIF : public SomeInterfaceIF
{
    public:
        virtual string getName() {
            // do something here            
        }
        virtual string getValue() {
            // do something here            
        }

        bool operator ==(const DerivedFromSomeInterfaceIF& right) const {
            // do something here
        }
        bool operator !=(const DerivedFromSomeInterfaceIF& right) const {
            // do something here            
        }          

    private:
        string thename;
        string thevalue;
};

int main(int argc, char *argv[])
{
    DerivedFromSomeInterfaceIF intIf;
    
    system("PAUSE");
    return EXIT_SUCCESS;
}

I'm I correct that the two definitions serve no purpose since they are no marked as pure virtual and no implementation in provided?

Thanks.

[Paul McKenzie]

What are the two non-virtual functions

bool operator ==(const DerivedFromSomeInterfaceIF& right) const
bool operator !=(const SomeInterfaceIF& rhs) const;

in SomeInterfaceIF class doing, if anything?

Read up on operator overloading. Those are overloaded calls to operator == and operator !=. The first determines if the current object is "equal to" the right, and the second determins if the current object is not equal to rhs.

There is no cooresponding .cpp file with any implementation for them.

The code you posted shows there is an implementation in the header file, and I guess your job is to fill in this implementation.

You main() function does not demonstrate these operators sufficiently.

int main(int argc, char *argv[])
{
    DerivedFromSomeInterfaceIF intIf;
    DerivedFromSomeInterfaceIF intIf2;
    if ( intIf == intIf2)
    {
        // they are equal
    }
    if ( intIf != intIf2)
    {
        // they are not equal
    }
}

So whatever makes those two objects equal or not equal is what goes in those empty function calls. That is up to the coder as to what constitutes equality or non-equality for those two objects.

Regards,

Paul McKenzie

[Yadrif]

I understand that the functions are operator overloads but specfically the ones in SomeInterfaceIF class are not marked as virtual but the other two functions in that class are pure virtual.

It seems to me that this creates a wierd situation since SomeInterfaceIF class can not be instanciated (because it contains pure virtual functions) so the point in having a non-virtual function in a class with a pure virtual function is pointless since the non-virtual function would not "flow down" to sub classes.

Am correct in how I'm thinking about this?

Thanks.

[Paul McKenzie]

I understand that the functions are operator overloads but specfically the ones in SomeInterfaceIF class are not marked as virtual but the other two functions in that class are pure virtual.

An unimplemented function means that it cannot be called. This means that you cannot call the base class's operator == and operator != from the derived class.

You can call operator == for your derived (the code I posted shows this is possible), but you can't call the parent's version.

bool operator ==(const DerivedFromSomeInterfaceIF& right) const 
{
    bool retval =  SomeInterfaceIF::operator==(right);  // linker error
    bool retval2 = false;
    if ( retval )
    {
         // determine if my derived objects are equal
         retval2 = whatever;
    }
    return retval & retval2;
}

The first line should give a linker error, since the parent operator == is not implemented. This prevents persons deriving from the class to mistakingly try and test base objects for equality or inequality.

Regards,

Paul McKenzie

[Yadrif]

I'm starting to get it but still a little confused.

Since the base class (SomeInterfaceIF) can not be instanciated how can someone attempt to test base objects for equility or inequality?

Thanks for helping.

[laserlight]

Since the base class (SomeInterfaceIF) can not be instanciated how can someone attempt to test base objects for equility or inequality?

You could have a derived class that provides a dummy implementation to override the pure virtual functions, and then test the inherited operator== and operator!=.

EDIT:
I might not be thinking correctly though. In order to work correctly, operator== may need to compare the entire state of the objects. A derived class may introduce new member variables, so the state of the base class object would then be a proper subset of the state of the derived class object.

[Graham]

Consider:

class abstract
{
public:
	abstract(int i) : mem(i) {}

   int get_value() const { return mem; }
   virtual void somefunction() = 0;

private:
	int mem;
};

class concrete : public abstract
{
public:
	concrete(int i) : abstract(i) {}

	void somefunction() { /* implementation */ }
};

int main()
{
	abstract* a = new concrete(5);

	int j = a->get_value();
	a->somefunction();

	delete a;
}

So, yes, you can call the non-virtual function declared in an abstract class.

[Yadrif]

Graham,
The sample code I posted had no implementation for the non-virtual functions which is why I was questioning the purpose of them.

I'm still not exactly sure. I'll re-read laserlight's post and hopefully things will start to sink in.

Thanks.

[Paul McKenzie]

I'm starting to get it but still a little confused.

Since the base class (SomeInterfaceIF) can not be instanciated

It is instantiated when you instantiate a derived class. So you're starting off with wrong information to begin with.

When you create a derived object, the parent comes along with it. If the parent has protected and public functions, the derived class can call them. This doesn't change just because the base class is abstract or not.

Regards,

Paul McKenzie

[Yadrif]

The issue here is that the base class has no implmentation for the overloaded operator functions, only a declaration, so I don't see how they could be called by the derived object.

So I'm questioning if the declarations serve any purpose.

Thanks.

[Hermit]

The issue here is that the base class has no implmentation for the overloaded operator functions, only a declaration, so I don't see how they could be called by the derived object.

So I'm questioning if the declarations serve any purpose.

Thanks.

If an unimplemented function is called somewhere in your code, then a linker error would be generated. In your example, SomeInterfaceIF::operator== is never called, so there isn't an error, however in this case there is no good reason to declare the function and never define it.

One of the few examples of where it is useful to declare, but not define a method is when making a class non-copyable:

class NonCopyable
{
private:
    // these don't need to be implemented
    NonCopyable(const NonCopyable &);
    void operator=(const NonCopyable &);
};

[Paul McKenzie]

The issue here is that the base class has no implmentation for the overloaded operator functions, only a declaration, so I don't see how they could be called by the derived object.

Right. But the compiler will not give you an error if you called them. As far as C++ is concerned, it is perfectly valid to call an unimplemented function. That is the trick -- it is the linker that will generate the error, not the compiler.

So I'm questioning if the declarations serve any purpose.

Usually functions that are declared but not defined are used to make sure that the person using the class does not inadvertantly use it in some way. The linker is used as the shield against this.

As Hermit pointed out, copy construction and assignment are two such functions where you may see declarations but not definitions. This is to ensure that the person using the class can never make copies of it. Don't be surprised if on an interview, you're asked "how do you prevent programmers from inadvertantly making copies of an object?". This thread has given you the answer.

To a much lesser extent, other functions are coded this way for the same reasons. Very rarely, if ever, do you see an == and != coded this way. But these two functions are overloaded many times, so maybe the coder is being extra-protective to make sure that when a derived class does overload it, the derived class's implementation doesn't attempt a base class copy.

Regards,

Paul McKenzie