*auto virtual* feature

N

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::doStuff()
AdvancedFunky::doStuff()

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

David White

nenad said:
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::doStuff()
AdvancedFunky::doStuff()

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

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
 
M

Michael Mellor

nenad said:
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::doStuff()
AdvancedFunky::doStuff()

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

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::doStuff()\n";
}

};

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

Michael Mellor
 
K

Keith H Duggar

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::dostuff() ;
// 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::doStuff()
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::dostuff() ;
}

} ;

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"?
 
N

nenad

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::dostuff() ;
// 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::doStuff()
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::dostuff() ;
}

} ;

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"?


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

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::dostuff() ;
// do advanced stuff
}

} ;

This achieves the behavior you want quite easily without a language
extension and without virtual functions.

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::doStuff();
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::doMyStuff();
doMyStuff();
}
protected: void doMyStuff(){
// do more stuff
}
};

class AdvancedFunky: virtual public Funky{

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

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
Funky::doMyStuff();
MoreFunky::doMyStuff();
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
 
J

Jonathan Turkanis

nenad said:
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::doStuff()
AdvancedFunky::doStuff()

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

How would you implement it?

Jonathan
 
K

Keith H Duggar

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 "constructor 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 << "constructor\n" ;
Derv2 derv2 ;
std::cout << "\nfunction\n" ;
derv2.reset() ;
derv2.print() ;

return 0 ;
}
 
N

nenad

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 "constructor like" behavior.

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.
 
R

Rolf Magnus

nenad said:
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.

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.
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.

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.
The one that duplicates children objects and handles future derived
classes well.

How would your suggestion help here?
 
J

Jonathan Turkanis

nenad said:
On the compiler level of course.

Of course.
I don't see a problem in implementing it.

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
 
M

Michael Mellor

nenad said:
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.
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=(Base &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
 
N

nenad

Jonathan Turkanis said:
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?

* 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
*constructorlike* ( 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.
 
N

nenad

Michael Mellor wrote
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

Yes, that exactly was reason for suggesting something like
*constructorlike* 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 * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

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

You'd probably need come kind of virtual copy() function that is
called from Base::eek:perator=(). 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.
 
M

Michael Mellor

nenad said:
Michael Mellor wrote



Yes, that exactly was reason for suggesting something like
*constructorlike* 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 * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

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

You'd probably need come kind of virtual copy() function that is
called from Base::eek:perator=(). 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.

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
 
R

Rolf Magnus

nenad said:
Michael Mellor wrote

Yes, that exactly was reason for suggesting something like
*constructorlike* 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 * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

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

You'd probably need come kind of virtual copy() function that is
called from Base::eek:perator=().

That still won't work. operator= can't change the class of the object it
is called for. And your language extenstion won't change anything about
that fact.
 
J

Jonathan Turkanis

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.

I'm not convinced this is simple.In general, with virtual inheritance,
there can be more than one virtual table per class. Constructors
insert pointers to the correct vtables a construction. I think you
need more detail here.

Best Regards,

Jonathan
 
N

nenad

I'm not convinced this is simple.In general, with virtual inheritance,
there can be more than one virtual table per class. Constructors
insert pointers to the correct vtables a construction. I think you
need more detail here.

Well I newer said I had an ambition to implement it. I'm sure someone
smarter than me can do it properly.
 
R

Rolf Magnus

nenad said:
Well I newer said I had an ambition to implement it. I'm sure someone
smarter than me can do it properly.

Adding a language feature always needs to consider two sides. The
programmer's side and the compiler writer's side.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,577
Members
45,054
Latest member
LucyCarper

Latest Threads

Top