Operator overloading vs. class derivation/inheritance

[Massimo Soricetti]

Hello,

recently I wrote a little class which has to wrap two different type of
data, showing the same external interface.

I used operator overloading, but the same result I could eventually
obtain with two classes derived from an abstract base class containing
only the interface functions. So, when it's worth to use overloading
mechanism instead of abstract/inherited?

 

[Ben Pope]

Hello,

recently I wrote a little class which has to wrap two different type of
data, showing the same external interface.

I used operator overloading, but the same result I could eventually
obtain with two classes derived from an abstract base class containing
only the interface functions. So, when it's worth to use overloading
mechanism instead of abstract/inherited?

I think you'll have to define your example a little better.

Perhaps some code?

Ben Pope

 

[Massimo Soricetti]

Ben Pope ha scritto:

I think you'll have to define your example a little better.

Perhaps some code?

Sure, here it is (TipoCodeRef and TipoDato are "typedef enum"s):

<code>
#define XREF_CODICE true
#define XREF_DATA false

class Xref
{
private:
int TipoFonte;
static bool TipoReference; //true: code; false: data
public:
int Segmento;
unsigned int Offset;

inline Xref(TipoCodeRef F, int S, unsigned int O):
TipoReference(XREF_CODICE),
{
TipoFonte = int(F);
Segmento = S;
Offset = O;
};

inline Xref(TipoDato F, int S, unsigned int O): TipoReference(XREF_DATI),
{
TipoFonte = int(F);
Segmento = S;
Offset = O;
};

Xref(TipoCodeRef F, -1, unsigned int O);
Xref(TipoDato F, -1, unsigned int O);

// non negativa se è un reference a codice
inline TipoCodeRef GetRefType (void)
{
TipoReference ?
return TipoCodeRef(TipoFonte) :
return -1;
};

// non negativa se è un reference a dati
inline TipoDato GetRefType (void)
{
TipoReference ?
return -1 :
return TipoDato(TipoFonte);
};

inline bool IsCodeRef (void) {return TipoReference;};
};

</code>

 

[Daniel T.]

Hello,

recently I wrote a little class which has to wrap two different type of
data, showing the same external interface.

I used operator overloading, but the same result I could eventually
obtain with two classes derived from an abstract base class containing
only the interface functions. So, when it's worth to use overloading
mechanism instead of abstract/inherited?

After looking over your code, I can't see where you did any operator
overloading, but anyway...

With the class you wrote, it's obvious that clients need to know which
type of data is contained in the object and be ready to handle either
type. This would be considered a bad idea in OO (ie using inheritance is
frowned upon in this type of situation.)

I can't help but wonder why you are combining the two different
data-types in one class?

 

[Massimo Soricetti]

After looking over your code, I can't see where you did any operator
overloading, but anyway...

Oops... you are right, it's function overloading... :-|

With the class you wrote, it's obvious that clients need to know which
type of data is contained in the object and be ready to handle either
type. This would be considered a bad idea in OO (ie using inheritance is
frowned upon in this type of situation.)

So it's better to create an abstract base class and derive two other
classes from it in this situation? Any client of this class will manage
only one type of reference, so it calls only the function returning the
type it needs.

 

[roberts.noah]

Oops... you are right, it's function overloading... :-|



So it's better to create an abstract base class and derive two other
classes from it in this situation? Any client of this class will manage
only one type of reference, so it calls only the function returning the
type it needs.

It all depends on your needs. There is no one answer to your question.

That said, I work daily on code that used overloading instead of
polymorphism in a "dispatch" system. This means that yes, all clients
have to know what type they are working with and worst, you can never
use the generic type as the compiler won't know what to do with it; if
you have a pointer to the generic you have to establish what subclass
it is and cast it to a pointer of that type in order to call the
function. In this case there are some times when you need to do
something different with one type or the other (code breaks LSP
bigtime) but IMHO it should have been done in a function expecting the
generic type (it should have established if this was a special needs
type and put it where it wanted) or at the least only override in the
case when something different need be done; I expect someone though
maybe something different would be done down the road and so just
overrode for everything...you should see the switch statement during
the file read that does something like:

switch (readType)
case BLH_TYPE:
thingy->Dispatch(new BlhType(data)); // parsing constructor
break;
case BLF_TYPE:
thingy->Dispatch(new BlfType(data));
break;
....

Where I come from we call that fugly and it has a very bad odor (of
course the whole overloading thing is just one smell in this case, but
it is a bad one).

 

[Daniel T.]

Oops... you are right, it's function overloading... :-|



So it's better to create an abstract base class and derive two other
classes from it in this situation? Any client of this class will manage
only one type of reference, so it calls only the function returning the
type it needs.

No, it would be better to have two different classes, because clients
need to know what types they have.