*auto virtual* feature

[nenad]

Wouldn't it be nice if we could do something like this:

class Funky{

public: auto virtual void doStuff(){
// dostuff
}

};

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
}

};

main(){

AdvancedFunky f;
f.doStuff();
}


Now, call to *auto virtual* member doStuff() should follow the same
logic as a constructor call in inheritance chain, i. e. when calling
f.doStuff() we got all doStuff() functions executed from bottom up:

Funky::doStuff( )
MoreFunky::doSt uff()
AdvancedFunky:: doStuff()

I think this feature could save us a lot of headache.

[David White]

Re: *auto virtual* feature

"nenad" <nenad@medix.co m.hr> wrote in message
news:41b24c70.0 401250144.1c728 78b@posting.goo gle.com...[color=blue]
> Wouldn't it be nice if we could do something like this:
>
> class Funky{
>
> public: auto virtual void doStuff(){
> // dostuff
> }
>
> };
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> // do more stuff
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> // do advanced stuff
> }
>
> };
>
> main(){
>
> AdvancedFunky f;
> f.doStuff();
> }
>
>
> Now, call to *auto virtual* member doStuff() should follow the same
> logic as a constructor call in inheritance chain, i. e. when calling
> f.doStuff() we got all doStuff() functions executed from bottom up:
>
> Funky::doStuff( )
> MoreFunky::doSt uff()
> AdvancedFunky:: doStuff()
>
> I think this feature could save us a lot of headache.[/color]

It is unnecessary and would not likely affect the sales of paracetamol
significantly. Furthermore, it is not for the class at the top to pronounce
from on high how another class's virtual functions should operate.

DW

[Michael Mellor]

Re: *auto virtual* feature

nenad wrote:
[color=blue]
> Wouldn't it be nice if we could do something like this:
>
> class Funky{
>
> public: auto virtual void doStuff(){
> // dostuff
> }
>
> };
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> // do more stuff
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> // do advanced stuff
> }
>
> };
>
> main(){
>
> AdvancedFunky f;
> f.doStuff();
> }
>
>
> Now, call to *auto virtual* member doStuff() should follow the same
> logic as a constructor call in inheritance chain, i. e. when calling
> f.doStuff() we got all doStuff() functions executed from bottom up:
>
> Funky::doStuff( )
> MoreFunky::doSt uff()
> AdvancedFunky:: doStuff()
>
> I think this feature could save us a lot of headache.[/color]

What is the problem with writing the following?

class Funky{
public: virtual void doStuff(){
std::cout << "Funky::doStuff ()\n";
}
};

class MoreFunky: public Funky{
public: void doStuff(){
Funky::doStuff( );
std::cout << "MoreFunky::doS tuff()\n";
}

};

class AdvancedFunky: public MoreFunky{
public: void doStuff(){
MoreFunky::doSt uff();
std::cout << "AdvancedFunky: :doStuff()\n";
}
};

Michael Mellor

[Keith H Duggar]

Re: *auto virtual* feature

> I think this feature could save us a lot of headache.

Would this really save that much? I don't see what it saves other than
writing one line in each function, i.e. :

class Funky{

public : doStuff() {
// dostuff
}

} ;

class MoreFunky: public Funky{

public: void doStuff(){
Funky::dostuff( ) ;
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
MoreFunky::dost uff() ;
// do advanced stuff
}

} ;

This achieves the behavior you want quite easily without a language
extension and without virtual functions. Moreover, it allows you to
control the order of the functions calls. Suppose you want to have
them executed in order :

AdvancedFunky:: doStuff()
MoreFunky::doSt uff()
Funky::doStuff( )

then just change the code to :

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
Funky::dostuff( ) ;
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
MoreFunky::dost uff() ;
}

} ;

Or any other mix you prefer. How would this be accomplished with "auto
virtual"? Would be need another keyword such as "reverse auto virtual"
or "retro virtual"?

[nenad]

Re: *auto virtual* feature

duggar@mit.edu (Keith H Duggar) wrote in message news:<b47de02.0 401250805.16d89 2c3@posting.goo gle.com>...[color=blue][color=green]
> > I think this feature could save us a lot of headache.[/color]
>
> Would this really save that much? I don't see what it saves other than
> writing one line in each function, i.e. :
>
> class Funky{
>
> public : doStuff() {
> // dostuff
> }
>
> } ;
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> Funky::dostuff( ) ;
> // do more stuff
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> MoreFunky::dost uff() ;
> // do advanced stuff
> }
>
> } ;
>
> This achieves the behavior you want quite easily without a language
> extension and without virtual functions. Moreover, it allows you to
> control the order of the functions calls. Suppose you want to have
> them executed in order :
>
> AdvancedFunky:: doStuff()
> MoreFunky::doSt uff()
> Funky::doStuff( )
>
> then just change the code to :
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> // do more stuff
> Funky::dostuff( ) ;
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> // do advanced stuff
> MoreFunky::dost uff() ;
> }
>
> } ;
>
> Or any other mix you prefer. How would this be accomplished with "auto
> virtual"? Would be need another keyword such as "reverse auto virtual"
> or "retro virtual"?[/color]


:) Well, maybe the choice of "auto" is a bit stupid ( I just took
first kw that came to my mind). More appropriate would be
"constructorlik e" :)

[color=blue]
> Would this really save that much? I don't see what it saves other than
> writing one line in each function, i.e. :
>
> class Funky{
>
> public : doStuff() {
> // dostuff
> }
>
> } ;
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> Funky::dostuff( ) ;
> // do more stuff
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> MoreFunky::dost uff() ;
> // do advanced stuff
> }
>
> } ;
>
> This achieves the behavior you want quite easily without a language
> extension and without virtual functions.[/color]

Yes. It is nice in this trivial case. But I don't *want* this kind of
behavior. What I want is constructor-like behavior. Consider this:

class Funky{

public: void doStuff(){
// do stuff
}
};

class MoreFunky: virtual public Funky{

public: void doStuff(){
Funky::doStuff( );
// do more stuff
}
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
Funky::doStuff( );
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
MoreFunky::doSt uff();
AdvancedFunky:: doStuff();
// do super stuff
}
};

Now it becomes messy because Funky::doStuff( ) is called twice. And it
gets worse as we multiple-inherit further - more and more
Funky::doStuff( )'s are called.
I made a little mistake putting focus on *virtual member functions*.
The issue here is *multiple/virtual inheritance*.
When we multiple inherit, the virtual inheritance mechanism eliminates
duplicate calls to base class constructors. Why not allow this kind of
behavior to ordinary functions (of course if we want to)?
The constructor call logic is pretty straightforward - each
constructor participates in initialisation of it's own piece of final
object. And it happens automatically, the compiler takes care of this.
Is's not hard to imagine the member function could act the same way -
changing it's piece of object down the inheritance chain( skiping the
duplicate base-calls in case of virtual inheritance).
The best solution to this problem ( at least to my humble knowledge )
is something like this:

class Funky{

public: void doStuff(){
doMyStuff();
}
protected: void doMyStuff(){
// do stuff
}

};

class MoreFunky: virtual public Funky{

public: void doStuff(){
Funky::doMyStuf f();
doMyStuff();
}
protected: void doMyStuff(){
// do more stuff
}
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
Funky::doMyStuf f();
doMyStuff();
}
protected: void doMyStuff(){
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
Funky::doMyStuf f();
MoreFunky::doMy Stuff();
AdvancedFunky:: doMyStuff();
doMyStuff();
}
protected: void doMyStuff(){
// do super stuff
}
};

This is pretty ugly as we now have to manage parasite doStuff() member
which does nothing except bunch of calls to doMyStuff()'s. The list of
calls gets biger as we inherit more. Imagine what class would look
like if we'd have dozens of members like this. On top of that, we must
have knowlege of whole inheritance tree if we're up to deriving the
new class.
Instead, I would like to have:

class Funky{

public: constuctorlike void doStuff(){
// do stuff
}
};

class MoreFunky: virtual public Funky{

public: void doStuff(){
// do more stuff
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
// do super stuff
}
};

The similarity with virtual member is that you define behavior of the
function in base class and it continues to behave that way in all
derived classes. That's what I meant by *auto virtual*. If that
function is at the same time virtual, one would declare it like:

auto virtual virtual void doStuff();

//or better:

constructorlike virtual void doStuff();

//or some fancy new keyword

:)
well, I'm probably talking total bs

[Jonathan Turkanis]

Re: *auto virtual* feature


"nenad" <nenad@medix.co m.hr> wrote in message
news:41b24c70.0 401250144.1c728 78b@posting.goo gle.com...[color=blue]
> Wouldn't it be nice if we could do something like this:
>
> class Funky{
>
> public: auto virtual void doStuff(){
> // dostuff
> }
>
> };
>
> class MoreFunky: public Funky{
>
> public: void doStuff(){
> // do more stuff
> }
>
> };
>
> class AdvancedFunky: public MoreFunky{
>
> public: void doStuff(){
> // do advanced stuff
> }
>
> };
>
> main(){
>
> AdvancedFunky f;
> f.doStuff();
> }
>
>
> Now, call to *auto virtual* member doStuff() should follow the same
> logic as a constructor call in inheritance chain, i. e. when calling
> f.doStuff() we got all doStuff() functions executed from bottom up:
>
> Funky::doStuff( )
> MoreFunky::doSt uff()
> AdvancedFunky:: doStuff()
>
> I think this feature could save us a lot of headache.[/color]

How would you implement it?

Jonathan

[Keith H Duggar]

Re: *auto virtual* feature

Oh ok, now that you've mentioned virtual inheritance I think I
understand more clearly what you are looking for. I agree that the
working solution you came up with isn't ideal since it does require
knowledge of the entire inheritance tree and lots of function
tracking.

It is an interesting idea you have to give constructor like behavior
to regular functions. I'd love to hear more informed commentary on the
topic than I can offer. What do you think of this runtime solution? (
I've renamed things a bit for simplicity I hope you don't mind the
change. ) It does eliminate the need for knowing the entire
inheritance hierarchy but necessitates an extra state variable in each
instance as well as an auxiliary function. Clearly not as convenient
as support for "constructo r like" behavior.

#include <iostream>

class Base {
bool __print ;
public :
Base ( ) { print ( ) ; }
void reset ( ) { __print = true ; }
void print ( ) {
if ( __print ) {
std::cout << "Base\n" ;
__print = false ;
}
}
} ;

class Derv1A : virtual public Base {
bool __print ;
public :
Derv1A ( ) { print ( ) ; }
void reset ( ) {
Base::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Base::print() ;
std::cout << "Derv1A\n" ;
__print = false ;
}
}
} ;

class Derv1B : virtual public Base {
bool __print ;
public :
Derv1B ( ) { print ( ) ; }
void reset ( ) {
Base::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Base::print() ;
std::cout << "Derv1B\n" ;
__print = false ;
}
}
} ;

class Derv2 : public Derv1A , public Derv1B {
bool __print ;
public :
Derv2 ( ) { print ( ) ; }
void reset ( ) {
Derv1A::reset () ;
Derv1B::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Derv1A::print() ;
Derv1B::print() ;
std::cout << "Derv2\n" ;
__print = false ;
}
}
} ;

int main ( int argc , char * argv[] ) {

std::cout << "constructo r\n" ;
Derv2 derv2 ;
std::cout << "\nfunction \n" ;
derv2.reset() ;
derv2.print() ;

return 0 ;
}

[nenad]

Re: *auto virtual* feature

>[color=blue]
> How would you implement it?
>
> Jonathan[/color]

On the compiler level of course.
I don't see a problem in implementing it.

[nenad]

Re: *auto virtual* feature

> What do you think of this runtime solution? ([color=blue]
> I've renamed things a bit for simplicity I hope you don't mind the
> change. ) It does eliminate the need for knowing the entire
> inheritance hierarchy but necessitates an extra state variable in each
> instance as well as an auxiliary function. Clearly not as convenient
> as support for "constructo r like" behavior.[/color]

Yes, but now you have extra calls to Base::reset(). Ok, it's a
reasonable trade-off for not needing to know the whole hierarchy tree.
But this implementation still looks confusing and the whole thing
feels like doing some kind of a language hack. Having constructor-like
members in this case feels kinda right.
Take a look at the case I'm stuck with:

#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base();
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

It's a polymorphic tree structure. I'd really like to see the
implementation of virtual operator=(...) here. The one that duplicates
children objects and handles future derived classes well.

[Rolf Magnus]

Re: *auto virtual* feature

nenad wrote:
[color=blue][color=green]
>> What do you think of this runtime solution? (
>> I've renamed things a bit for simplicity I hope you don't mind the
>> change. ) It does eliminate the need for knowing the entire
>> inheritance hierarchy but necessitates an extra state variable in
>> each instance as well as an auxiliary function. Clearly not as
>> convenient as support for "constructo r like" behavior.[/color]
>
> Yes, but now you have extra calls to Base::reset(). Ok, it's a
> reasonable trade-off for not needing to know the whole hierarchy tree.
> But this implementation still looks confusing and the whole thing
> feels like doing some kind of a language hack. Having constructor-like
> members in this case feels kinda right.[/color]

Usually, you should split your function up into a non-virtual part that
is done in the base class and a private virtual function in the derived
classes.
[color=blue]
> Take a look at the case I'm stuck with:
>
> #include <list>
>
> using std::list;
>
> class Base {
> int base_data;
> list< Base* > children;
> Base * parent;
>
> public: virtual ~Base();
> };
>
> class Derv1A : virtual public Base {
> int deriv1a_data;
> };
>
> class Derv1B : virtual public Base {
> int deriv1b_data;
> };
>
> class Derv2 : public Derv1A , public Derv1B {
> int deriv2_data;
> };
>
> It's a polymorphic tree structure. I'd really like to see the
> implementation of virtual operator=(...) here.[/color]

A virtual operator= isn't very useful, since it would need to alter the
class of the object it's called for when used polymorphically . That,
however, isn't possible.
[color=blue]
> The one that duplicates children objects and handles future derived
> classes well.[/color]

How would your suggestion help here?

[Jonathan Turkanis]

Re: *auto virtual* feature


"nenad" <nenad@medix.co m.hr> wrote in message
news:41b24c70.0 401260809.588ae f55@posting.goo gle.com...[color=blue][color=green]
> >
> > How would you implement it?
> >
> > Jonathan[/color]
>
> On the compiler level of course.[/color]

Of course.
[color=blue]
> I don't see a problem in implementing it.[/color]

I asked how, not whether you see a problem. Would the compiler just
add code at the beginning of the function body statically invoking the
function for the immediate base class? How is this virtual?

Jonathan

[Michael Mellor]

Re: *auto virtual* feature

nenad wrote:
[color=blue][color=green]
>>What do you think of this runtime solution? (
>>I've renamed things a bit for simplicity I hope you don't mind the
>>change. ) It does eliminate the need for knowing the entire
>>inheritance hierarchy but necessitates an extra state variable in each
>>instance as well as an auxiliary function. Clearly not as convenient
>>as support for "constructo r like" behavior.[/color]
>
>
> Yes, but now you have extra calls to Base::reset(). Ok, it's a
> reasonable trade-off for not needing to know the whole hierarchy tree.
> But this implementation still looks confusing and the whole thing
> feels like doing some kind of a language hack. Having constructor-like
> members in this case feels kinda right.
> Take a look at the case I'm stuck with:
>
> #include <list>
>
> using std::list;
>
> class Base {
> int base_data;
> list< Base* > children;
> Base * parent;
>
> public: virtual ~Base();
> };
>
> class Derv1A : virtual public Base {
> int deriv1a_data;
> };
>
> class Derv1B : virtual public Base {
> int deriv1b_data;
> };
>
> class Derv2 : public Derv1A , public Derv1B {
> int deriv2_data;
> };
>
> It's a polymorphic tree structure. I'd really like to see the
> implementation of virtual operator=(...) here. The one that duplicates
> children objects and handles future derived classes well.[/color]
How does a *virtual* operator= help here?
Yould could just
#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base() { };
Base &operator=(B ase &other) {
// Do deep copy
return *this;
}
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

int main ( ) {
Derv2 a, b;
b = a;
}

and except that there is a possibility of the operator= being called
twice, or do some clever code to avoid the penalty of two deep copies
but I dont see how a virtual operator= helps in either case?

Michael Mellor

[nenad]

Re: *auto virtual* feature

"Jonathan Turkanis" <technews@kanga roologic.com> wrote
[color=blue]
> I asked how, not whether you see a problem. Would the compiler just
> add code at the beginning of the function body statically invoking the
> function for the immediate base class? How is this virtual?[/color]

* statically invoking the function for the immediate base class *
could be done by typing it. Main problem is what to do in case of
virtual inheritance to avoid overlapping base-calls.

Ok I was sloppy with choice of *keyword(s)*. Virtual in *auto virtual*
is reffering to proper behavior in context of virtual inheritance.
Let's forget about *auto virtual* and call this behavior
*constructorlik e* ( just for the sake of clarity ).

You would declare ordinary constructorlike member:

constructorlike void func();

When you call such a function compiler would statically generate
series of all base-calls ( bottom-up ) avoiding duplicate calls in
case of virtual inheritance. Note that this is useless if you don't
have virtual-inherited class hierarchy.

Or if the function is virtual:

constructorlike virtual void func();

Imlementation here depends on how virtual calls are done. For most
common case using vptr+vtable compiler would generate a loop that
walks up the vtable, calling available functions, finishing at table
pointed by vptr. So no extra hidden data per object is needed ( of
course, this is extremely simplified explanation ).
Anyway I wouldn't mind if some additional hidden data is involved - as
in the case of virtual calls - you somehow must pay for a fancy ride.

[nenad]

Re: *auto virtual* feature

Michael Mellor wrote[color=blue]
> and except that there is a possibility of the operator= being called
> twice, or do some clever code to avoid the penalty of two deep copies[/color]

Yes, that exactly was reason for suggesting something like
*constructorlik e* member function; to avoid multiple calls without
doing the clever code.

How would you implement operator= here:

#include <list>

using std::list;

class Base {
list< Base* > children;
Base * parent;
};

class Derv1A : virtual public Base {
char * needsToBeDuplic ated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplic ated2;
};

class Derv2 : public Derv1A , public Derv1B {
char * needsToBeDuplic ated3;
};

You'd probably need come kind of virtual copy() function that is
called from Base::operator= (). But this is painful as every copy() in
derived class must implement whole copying code that is already
implemented in base classes. Or you can use scheme in which every
copy() does it's own copying and calls all immediate-base copy()'s,
propagating calls to the top hence doing multiple calls to same
base-members. The number of unnecessary calls could get quite big if
you have large inheritance tree.
If we'd have some kind of automatic constructor-like behavior attached
to copy() this would no lenger be a problem.

[Michael Mellor]

Re: *auto virtual* feature

nenad wrote:[color=blue]
> Michael Mellor wrote
>[color=green]
>>and except that there is a possibility of the operator= being called
>>twice, or do some clever code to avoid the penalty of two deep copies[/color]
>
>
> Yes, that exactly was reason for suggesting something like
> *constructorlik e* member function; to avoid multiple calls without
> doing the clever code.
>
> How would you implement operator= here:
>
> #include <list>
>
> using std::list;
>
> class Base {
> list< Base* > children;
> Base * parent;
> };
>
> class Derv1A : virtual public Base {
> char * needsToBeDuplic ated1;
> };
>
> class Derv1B : virtual public Base {
> char * needsToBeDuplic ated2;
> };
>
> class Derv2 : public Derv1A , public Derv1B {
> char * needsToBeDuplic ated3;
> };
>
> You'd probably need come kind of virtual copy() function that is
> called from Base::operator= (). But this is painful as every copy() in
> derived class must implement whole copying code that is already
> implemented in base classes. Or you can use scheme in which every
> copy() does it's own copying and calls all immediate-base copy()'s,
> propagating calls to the top hence doing multiple calls to same
> base-members. The number of unnecessary calls could get quite big if
> you have large inheritance tree.
> If we'd have some kind of automatic constructor-like behavior attached
> to copy() this would no lenger be a problem.[/color]

Will you be assigning to the base object? because this will have problems.

Base *p = new Derv2;
Base *a = new Derv1A;
.....
p->copy(*a);
This is legal so you will need to implement runtime checks that the rhs
of the assignment is the object you expect it to be.

Personally I prefer to only assign to the object as its actual type.
Then you will only need the an operator= for Base which can use a simple
copy-on-write system to avoid the double copy. The default operator=
will be fine for the other classes.

Michael Mellor