Which derived class is it?

[Brad Marts]

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.
Can I tell which derived class is passed?

For example:

class Base
{ //...
};

class D1: public Base
{ //...
};

class D2: public Base
{ //...
};

void f(Base b)
{
// Do one thing if b is of type D1, Do another if b is of type D2
}

Is this the right idea? Or do I have to write multiple copies of f()
with arguments overloaded with the derived classes?

Brad

[jeffc]

"Brad Marts" <ma***@phy.duke .edu> wrote in message
news:pa******** *************** *****@phy.duke. edu...

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.
Can I tell which derived class is passed?

For example:

class Base
{ //...
};

class D1: public Base
{ //...
};

class D2: public Base
{ //...
};

void f(Base b)
{
// Do one thing if b is of type D1, Do another if b is of type D2
}

Is this the right idea? Or do I have to write multiple copies of f()
with arguments overloaded with the derived classes?

I would certainly not write multiple copies. You might want to read up more
on examples of polymorphism. The power of this is that you don't have to
write multiple copies of functions. On the other hand, you normally don't
want to have to check what the subtype is, either. Normally what you want
to do is achieve "performing differently" by calling functions on those
objects that get passed in. In other words, you bury the different
performance within the subclasses themselves. For example, in your f()
function, what do you want to do? Let's say it's to display something about
the object. So you write a function called "display" and put it in Base and
make it virtual. Then in D1 and D2 you define those functions again,
separately, but you make them do 2 different things. For example,

void D1::display()
{
cout << "This is an object of type D1!";
}

void D2::display()
{
cout << "This is an object of type D2!";
}

In your f function, you merely write
b.display(), and then the correct thing will be displayed, depending on the
type, without you having to know or care in the code. There's a catch here
though - you can't do it if you pass the Base parameter by value like that.
You have to pass it by reference (Base& b), or pionter (Base* pB).

[David Harmon]

On Mon, 15 Dec 2003 10:34:48 -0700 in comp.lang.c++, "Brad Marts"
<ma***@phy.duke .edu> was alleged to have written:

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.

This issue is covered in Marshall Cline's C++ FAQ. See the topic
"[20] Inheritance — virtual functions". It is always good to check the
FAQ before posting. You can get the FAQ at:
http://www.parashift.com/cpp-faq-lite/

[Deming He]

Brad Marts <ma***@phy.duke .edu> wrote in message
news:pa******** *************** *****@phy.duke. edu...

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.
Can I tell which derived class is passed?

For example:

class Base
{ //...
};

class D1: public Base
{ //...
};

class D2: public Base
{ //...
};

void f(Base b)
{
// Do one thing if b is of type D1, Do another if b is of type D2
}

Is this the right idea? Or do I have to write multiple copies of f()
with arguments overloaded with the derived classes?

Brad

The idea is all right. However the implementation is not quite right.

Your f function could be altered like this:

void f(Base& b)
{
if(typeid(b) == typeid(D1))/*Do one thing here*/

else if(typeid(b) == typeid(D2))/*Do another here*/
}

Basically used RTTI above.

[Jeff Schwab]

Brad Marts wrote:

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.

IMNSHO:

The worst of all possible worlds is to test the argument's run-time type
with a switch statement, if-else block, or the like (the "switch on
type" approach).

The next worst of all possible worlds is to code a different version of
the function for each derived type that may be an argument to it (the C
approach).

The usual solution is to give the base class a virtual method, giving
each derived class the option of overriding the method:

struct Base { virtual void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

void f( Base& b ) { b.behave( ); }

My favorite solution is the generic approach, which allows you to avoid
the performance and space overhead that accompany the use of virtual
functions:

struct Base { void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

template< typename T >
void f( T& t ) { t.behave( ); }

This causes the compiler to implement the indirection at compile time,
instead of run time. The biggest barrier I've had to using this
approach is the pile of existing code (written by yours truly) that
relies on run-time indirection.

Hth,
Jeff

[stelios xanthakis]

Jeff Schwab <je******@comca st.net> wrote in message news:<zb******* *************@c omcast.com>...

Brad Marts wrote:

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.
IMNSHO:

The worst of all possible worlds is to test the argument's run-time type
with a switch statement, if-else block, or the like (the "switch on
type" approach).

OT:
And that's why typeID was maybe a not-so-good idea. It can be malused.
The next worst of all possible worlds is to code a different version of
the function for each derived type that may be an argument to it (the C
approach).

C approach would be that each object will have a member my_type,
which will be used in a switch/if. non-OOP. callbacks would be
the other solution, but that's why C++ is here for.
The usual solution is to give the base class a virtual method, giving
each derived class the option of overriding the method:

struct Base { virtual void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

void f( Base& b ) { b.behave( ); }

You forgot inheritance?

struct Derrived1 : Base { ... };

Of course.
My favorite solution is the generic approach, which allows you to avoid
the performance and space overhead that accompany the use of virtual
functions:

struct Base { void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

template< typename T >
void f( T& t ) { t.behave( ); }

Here on the other hand, we don't need inheritance indeed.
'Derrived1' is not really Derrived but just named so.

Just some more info for the OP:

If -the polymorphic- function "f" has more code:

void f (T &t)
{
...lots of code...
t.behave();
...lots of code...
}

The extra code will be duplicated with each specialization
and thus is not suitable for "embedded systems" where available
memory is 640kb.

Moreover, we are studying a simple case with just one virtual
function. If f() calls two virtuals, "behave1" and "behave2"
then OOP is definitelly superior.
cheers,

stelios

[Patrick Kowalzick]

Hi Jeff,

The worst of all possible worlds is to test the argument's run-time type
with a switch statement, if-else block, or the like (the "switch on
type" approach).

The next worst of all possible worlds is to code a different version of
the function for each derived type that may be an argument to it (the C
approach).

Hmm, this leads me to the next question:

given the case you have to call a function depending on two Instances of a
class, what shall we do then?
I append a small example to demonstrate you the Problem I have. Additionally
there is another constraint: no function overloading (a real-world reason
:-( ) for the final function "kicking" which is called out of main.

Please take a closer look at the function kicking. The if..else table is a
real horror. But how to solve it in an easier way?

Regards,
Patrick

// CODE STARTS

#include <iostream>

// small hierachy
// abstact base class, virtual for RTTI
class mama {
protected:
mama() {};
virtual ~mama() {};
};
class daughter : public mama {};
class son : public mama {};
class son2 : public mama {};

// small action functors
template <typename T1,typename T2> struct kick;
template <typename T> struct kick<T,T>
{
void operator()() { std::cout << "Look mum, I am kicking me." <<
std::endl; }
};
template <> struct kick<son,daught er>
{
void operator()() { std::cout << "He, do not kick girls !!!" <<
std::endl; }
};
template <> struct kick<son2,daugh ter>
{
void operator()() { std::cout << "He, do not kick girls !!!" <<
std::endl; }
};
template <> struct kick<daughter,s on>
{
void operator()() { std::cout << "Aua, that hurts." << std::endl; }
};
template <> struct kick<daughter,s on2>
{
void operator()() { std::cout << "Aua, that hurts." << std::endl; }
};
template <> struct kick<son,son2>
{
void operator()() { std::cout << "son2 is crying running to mama" <<
std::endl; }
};
template <> struct kick<son2,son>
{
void operator()() { std::cout << "son is kicking back" << std::endl; }
};

// function which shall be executed
// uuuuuhhhhh, this is really ugly,
// just for a call kick<instancety pe(fam1_),insta ncetype(fam2_)> ()();
// I really expect typos
void kicking(const mama & fam1_,const mama & fam2_)
{
std::cout << typeid(fam1_).n ame() << " tries to kick ";
std::cout << typeid(fam2_).n ame() << ": ";

if ( typeid(daughter ) == typeid(fam1_) )
if ( typeid(daughter ) == typeid(fam2_) )
kick<daughter,d aughter>()();
else if ( typeid(son) == typeid(fam2_) )
kick<daughter,s on>()();
else if ( typeid(son2) == typeid(fam2_) )
kick<daughter,s on2>()();
else throw "Ups, what happend ?";
else if ( typeid(son) == typeid(fam1_) )
if ( typeid(daughter ) == typeid(fam2_) )
kick<son,daught er>()();
else if ( typeid(son) == typeid(fam2_) )
kick<son,son>() ();
else if ( typeid(son2) == typeid(fam2_) )
kick<son,son2>( )();
else throw "Ups, what happend ?";
else if ( typeid(son2) == typeid(fam1_) )
if ( typeid(daughter ) == typeid(fam2_) )
kick<son2,daugh ter>()();
else if ( typeid(son) == typeid(fam2_) )
kick<son2,son>( )();
else if ( typeid(son2) == typeid(fam2_) )
kick<son2,son2> ()();
else throw "Ups, what happend ?";
else throw "Ups, what happend ?";
}
// examples
int main()
{
kicking( son() , daughter() );
kicking( daughter() , son() );
kicking( son() , son() );
kicking( son() , son2() );
kicking( son2() , son() );
kicking( son2() , daughter() );

return 0;
}

// CODE ENDS

[Jeff Schwab]

stelios xanthakis wrote:

Jeff Schwab <je******@comca st.net> wrote in message news:<zb******* *************@c omcast.com>...

Brad Marts wrote:

I would like to have a function that takes as an argument a base class but
performs differently depending on which type of derived class is passed.

IMNSHO:

The worst of all possible worlds is to test the argument's run-time type
with a switch statement, if-else block, or the like (the "switch on
type" approach).

OT:
And that's why typeID was maybe a not-so-good idea. It can be malused.

The next worst of all possible worlds is to code a different version of
the function for each derived type that may be an argument to it (the C
approach).

C approach would be that each object will have a member my_type,
which will be used in a switch/if. non-OOP. callbacks would be
the other solution, but that's why C++ is here for.

Yes, you're right. Having different C-style functions, as I suggested,
does not provide polymorphism. However, it is possible to get
compile-time polymorphism using overloaded functions:

struct A { void f( ) { /* do one thing */ } };
struct B { void f( ) { /* do another */ } };
struct C { void f( ) { /* do yet another */ } };

void f( A& a ) { a.f( ); }
void f( B& b ) { b.f( ); }
void f( C& c ) { c.f( ); }

The usual solution is to give the base class a virtual method, giving
each derived class the option of overriding the method:

struct Base { virtual void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

void f( Base& b ) { b.behave( ); }

You forgot inheritance?

struct Derrived1 : Base { ... };

Of course.

You're right again. Sorry for omission of vital detail.

My favorite solution is the generic approach, which allows you to avoid
the performance and space overhead that accompany the use of virtual
functions:

struct Base { void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

template< typename T >
void f( T& t ) { t.behave( ); }

Here on the other hand, we don't need inheritance indeed.
'Derrived1' is not really Derrived but just named so.

Just some more info for the OP:

If -the polymorphic- function "f" has more code:

void f (T &t)
{
...lots of code...
t.behave();
...lots of code...
}

The extra code will be duplicated with each specialization
and thus is not suitable for "embedded systems" where available
memory is 640kb.

Moreover, we are studying a simple case with just one virtual
function. If f() calls two virtuals, "behave1" and "behave2"
then OOP is definitelly superior.

These are all OOP approaches. ITYM "run-time indirection."

-Jeff

[Jeremy Cowles]

"Jeff Schwab" <je******@comca st.net> wrote in message
news:zb******** ************@co mcast.com...

Brad Marts wrote:

I would like to have a function that takes as an argument a base class but performs differently depending on which type of derived class is passed.

IMNSHO:

The worst of all possible worlds is to test the argument's run-time type
with a switch statement, if-else block, or the like (the "switch on
type" approach).

The next worst of all possible worlds is to code a different version of
the function for each derived type that may be an argument to it (the C
approach).

The usual solution is to give the base class a virtual method, giving
each derived class the option of overriding the method:

struct Base { virtual void behave( ) { /* do one thing */ } };
struct Derived1 { void behave( ) { /* do another */ } };
struct Derived2 { void behave( ) { /* do yet another */ } };

void f( Base& b ) { b.behave( ); }

I am very new to C++, but I was wondering: what if the function f( ) does
not belong in the class? For example, say the class is logic for some
business process, which holds some displayable state, and function f( )
displays this state; wouldn't it be wrong to mix the GUI code in with the
logic?

Jeremy

[Nils Petter Vaskinn]

On Tue, 16 Dec 2003 02:53:04 -0800, stelios xanthakis wrote:

OT:
And that's why typeID was maybe a not-so-good idea. It can be malused.

So can sliced bread, but that doesn't mean it was a bad idea. Lots of good
thigs can be malused, the solution is not to do it.

Still I agree that most of the time an overloaded (I prefer virtual)
function will do better.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up