Virtual overloading of operators

[Jörg Rolef]

Hello,

I'd like to do a virtual overload of the operator<. If I do it like in
the example listed below, then I get an error message for accessing op.b
in SpecialContents:perator<(): "Member element Contents:p.b is
protected."
But I do not get an error for access of op.a in Contents:perator<().

First: Do I have to use public member functions to access the values of
the second operand? (First I thought that declaring the members as
protected would do me the job, but of course this seems only to make the
object's own elements acessible to descendant classes.)

Second: Why does the access of op.a in Contents:perator<() not lead to
an error message then? At least, op is a foreign object, so this access
should also lead to an error - am I wrong?

Greetings and thank you,
Jörg


class Contents
{
protected:
int a;
char b;

public:
// ...
virtual bool operator<(Contents& op);
};


bool Contents:perator<(Contents& op)
{
return (a < op.a);
// Returns no error for the access of op.a
}


class SpecialContents : public Contents
{
bool operator<(Contents& op);
};


bool SpecialContents:perator<(Contents& op)
{
return (b < op.b);
// Returns error: "Contents:p.b is protected"
}

 

[Jörg Rolef]

Hi,

You need to implement your 'b' comparison as a protected function of the
base class and call it from 'SpecialContents:perator<'.

thank you. Yes, it seems so.

IOW, protected data members are allowed to be
accessed only through 'this->'. IIRC, anyway.

As it seems now, protected data members of an object are accessible
1) through 'this->'
2) for other objects of the same class (because this example works

Greetings,
Jörg

 

[AnonMail2005]

Hello,

I'd like to do a virtual overload of the operator<. If I do it like in
the example listed below, then I get an error message for accessing op.b
in SpecialContents:perator<(): "Member element Contents:p.b is
protected."
But I do not get an error for access of op.a in Contents:perator<().

First: Do I have to use public member functions to access the values of
the second operand? (First I thought that declaring the members as
protected would do me the job, but of course this seems only to make the
object's own elements acessible to descendant classes.)

Second: Why does the access of op.a in Contents:perator<() not lead to
an error message then? At least, op is a foreign object, so this access
should also lead to an error - am I wrong?

Greetings and thank you,
Jörg

class Contents
{
protected:
        int     a;
        char    b;

public:
        // ...
        virtual bool operator<(Contents& op);

};

bool Contents:perator<(Contents& op)
{
        return (a < op.a);
           // Returns no error for the access of op.a

}

class SpecialContents : public Contents
{
        bool operator<(Contents& op);

};

bool SpecialContents:perator<(Contents& op)
{
        return (b < op.b);
           // Returns error: "Contents:p.b is protected"

}

It's probably a bad idea to make the comparison operator virtual.
Virtuals are usually meant to be called from base class pointers.
This way, the client code does not know anything about which derived
class the pointer points to.

If you have two different derived classes accessed through base class
pointers how would you compare them? Does each derived class need to
know how to compare itself to other derived classes? That's not
good. If the comparison operator only needs base class data members
to do the compare, then the operator shouldn't be virtual.

HTH

 

[Jörg Rolef]

Hi,

It's probably a bad idea to make the comparison operator virtual.
Virtuals are usually meant to be called from base class pointers.
This way, the client code does not know anything about which derived
class the pointer points to.

I don't believe that this is the source of my problem, since this is the
objective of derivation and virtualization. In fact, the virtuality of
operators is naturally the case with virtual base classes: Every member
function is virtual.

If you have two different derived classes accessed through base class
pointers how would you compare them? Does each derived class need to
know how to compare itself to other derived classes? That's not
good. If the comparison operator only needs base class data members
to do the compare, then the operator shouldn't be virtual.

No, there are in fact good reasons to even make the comparison operators
differ: I have one sort of objects in different flavours, and their
sorting behaves different in each flavour. But I need all flavours to be
interchangeable with each other, f.ex. they should all be collectable
and sortable in a container. If necessary, approbate comparison
functions must even be delivered for all cases where objects of "sibling
classes" will be compared.

I believe the concept is right, but it's merely an access problem.

Greetings,
Jörg

 

[AnonMail2005]

Hi,



I don't believe that this is the source of my problem, since this is the
objective of derivation and virtualization. In fact, the virtuality of
operators is naturally the case with virtual base classes: Every member
function is virtual.

I didn't say that was the source of your problem - just hinting that
your design may be suboptimal.

No, there are in fact good reasons to even make the comparison operators
differ: I have one sort of objects in different flavours, and their
sorting behaves different in each flavour. But I need all flavours to be
interchangeable with each other, f.ex. they should all be collectable
and sortable in a container. If necessary, approbate comparison
functions must even be delivered for all cases where objects of "sibling
classes" will be compared.

I believe the concept is right, but it's merely an access problem.

Your further description hints at even more design problems. But I'll
assume you know what you're doing and leave it at that.

Good luck.