Implementing member object's virtual functions

[v4vijayakumar]

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;
};

class test1
{
protected:
void fun() {}

private:
test t1;
};

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-04-09 13:36, v4vijayakumar wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;
};

class test1
{
protected:
void fun() {}

private:
test t1;
};

Can't do that. test is purely virtual so you can't instantiate it in
test1. Are you sure you don't want to use inheritance? That's the usual
usage of virtual:

class test1 : public test
{
protected:
void foo() {/*...*/}
};

--
Erik Wikström

[Fei Liu]

v4vijayakumar wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

No, it's not possible. You can do what you want by creating an
inheritance hierarchy of classes. You can implement the virtual function
in derived class.

Fei

>
ex:

class test
{
protected:
virtual void fun() = 0;
};

class test1
{
protected:
void fun() {}

private:
test t1;
};

[Rolf Magnus]

v4vijayakumar wrote:

Is it possible to implement member object's virtual functions, in the
containing class?

No. You cannot define member functions for single objects, only for whole
classes.

If not, is it possible to simulate this behavior?

You mean, other than deriving from "test", implementing it there, then make
an instance of that derived class a member of "test1"? No.
Your class "test" is abstract and can not be instantiated.

ex:

class test
{
protected:
virtual void fun() = 0;
};

class test1
{
protected:
void fun() {}

private:
test t1;
};

[v4vijayakumar]

On Apr 9, 4:36 pm, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;

};

class test1
{
protected:
void fun() {}

private:
test t1;

};

implementation by containment (?)

[Salt_Peter]

On Apr 9, 7:36 am, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;

};

class test1
{
protected:
void fun() {}

private:
test t1;

};

No, if the language allowed that then coupling would become a
nightmare.
Isn't class test meant to be abstract anyways?
Templates are not required but consider the implications:

#include <iostream>

class abstract
{
protected:
virtual void fun() = 0;
};

class concrete : public abstract
{
public:
void fun() { std::cout << "concrete::fun( )\n"; }
};

class another : public concrete
{
public:
void fun() { std::cout << "another::fun() \n"; }
};

// type M must implement void fun()
template< typename M >
class test
{
M m;
public:
void fun() { m.fun(); }
};

int main()
{
test< concrete t;
t.fun();

test< another a;
a.fun();
}
/*
concrete::fun()
another::fun()
*/

[v4vijayakumar]

On Apr 10, 9:23 am, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

On Apr 9, 4:36 pm, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;

};

class test1
{
protected:
void fun() {}

private:
test t1;

};

implementation by containment (?)

I don't know how usefull this, but I would like to know some valid
reasons to avoid this.

Salt_Peter wrote:

No, if the language allowed that then coupling would become a
nightmare.

Sorry, I don't see (couldn't understand ?!) any coupling issues.

Let me try to list down some more info. (May be, I am wrong)

1. while creating member object for an abstract class, the containing
class can be looked for valid implementation for the virtual
functions.

2. If there is no valid implementations then the member object
creation can be disallowed (results in a compile time error),
otherwise, member object construction can be allowed.

3. Any calls to member object's virtual function can be directed to
the implementation provided by the containing class.

4. I think, there is no need to maintain vtable for this containment
hierarchy.

5. old code calling new code ?!

[Salt_Peter]

On Apr 10, 10:48 am, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

On Apr 10, 9:23 am, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

On Apr 9, 4:36 pm, "v4vijayaku mar" <vijayakumar.su [e-mail] m>
wrote:

Is it possible to implement member object's virtual functions, in the
containing class? If not, is it possible to simulate this behavior?

ex:

class test
{
protected:
virtual void fun() = 0;

};

class test1
{
protected:
void fun() {}

private:
test t1;

};

implementation by containment (?)

I don't know how usefull this, but I would like to know some valid
reasons to avoid this.

Salt_Peter wrote:

No, if the language allowed that then coupling would become a
nightmare.

Sorry, I don't see (couldn't understand ?!) any coupling issues.

If the containing class held the implementation of a function declared
elsewhere than surely there would be coupling issues.

>
Let me try to list down some more info. (May be, I am wrong)

1. while creating member object for an abstract class, the containing
class can be looked for valid implementation for the virtual
functions.

There is no 'objects' in a class. A class/struct is a blueprint.
An instance of a class is an object,
and an abstract class can never be instantiated to be an object or a
member of an object.
Thats what 'abstract' means: the class is not allowed to be used to
instantiate a concrete object.
The term 'abstract' means you must derive and implement whatever is
pure-virtual before instantiating a derived object. It implies an
inheritence tree.

You should consider reading about abstract types, they are a powerful
concept (considerably more powerfull than you think them to be). Good
examples of these is std::ostream where the abstract type can be used
as a reference to a derived object safely.

>
2. If there is no valid implementations then the member object
creation can be disallowed (results in a compile time error),
otherwise, member object construction can be allowed.

Thats exactly what the example with the templated class does.

>
3. Any calls to member object's virtual function can be directed to
the implementation provided by the containing class.

no, since the containing class is not in the inheritance hierarchy.
Think of it this way: what you are trying to do is in fact doable. You
could conceivably use a function pointer and the appropriate
arguements/references to redirect a member function to call a sequence
of events held in the container object. However thats bad design, bug-
ridden and very expensive to maintain. Its ugly, hard to read, hard to
debug, difficult to explain, a bad concept, etc...

>
4. I think, there is no need to maintain vtable for this containment
hierarchy.

casting usually is more expensive than polymorphic mechanisms.
And most of the time, casting is much, much slower as well as
inherently unsafe.
Keep it simple and structured or pay the price.

>
5. old code calling new code ?!

what?