*auto virtual* feature

Discussion in 'C++' started by nenad, Jan 25, 2004.

  1. nenad

    nenad Guest

    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.
    nenad, Jan 25, 2004
    #1
    1. Advertising

  2. nenad

    David White Guest

    "nenad" <> wrote in message
    news:...
    > 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
    David White, Jan 25, 2004
    #2
    1. Advertising

  3. nenad wrote:

    > 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
    Michael Mellor, Jan 25, 2004
    #3
  4. > 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"?
    Keith H Duggar, Jan 25, 2004
    #4
  5. nenad

    nenad Guest

    (Keith H Duggar) wrote in message news:<>...
    > > 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"?



    :) 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
    nenad, Jan 25, 2004
    #5
  6. "nenad" <> wrote in message
    news:...
    > 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
    Jonathan Turkanis, Jan 25, 2004
    #6
  7. 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 ;
    }
    Keith H Duggar, Jan 26, 2004
    #7
  8. nenad

    nenad Guest

    >
    > How would you implement it?
    >
    > Jonathan


    On the compiler level of course.
    I don't see a problem in implementing it.
    nenad, Jan 26, 2004
    #8
  9. nenad

    nenad Guest

    > 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.
    nenad, Jan 26, 2004
    #9
  10. nenad

    Rolf Magnus Guest

    nenad wrote:

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


    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?
    Rolf Magnus, Jan 26, 2004
    #10
  11. "nenad" <> wrote in message
    news:...
    > >
    > > How would you implement it?
    > >
    > > Jonathan

    >
    > 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
    Jonathan Turkanis, Jan 26, 2004
    #11
  12. nenad wrote:

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

    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
    Michael Mellor, Jan 26, 2004
    #12
  13. nenad

    nenad Guest

    "Jonathan Turkanis" <> wrote

    > 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.
    nenad, Jan 27, 2004
    #13
  14. nenad

    nenad Guest

    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.
    nenad, Jan 27, 2004
    #14
  15. nenad wrote:
    > 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.


    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
    Michael Mellor, Jan 27, 2004
    #15
  16. nenad

    Rolf Magnus Guest

    nenad wrote:

    > 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=().


    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.
    Rolf Magnus, Jan 27, 2004
    #16
  17. "nenad" <> wrote in message
    news:...
    > "Jonathan Turkanis" <> wrote
    >


    >
    > 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
    Jonathan Turkanis, Jan 27, 2004
    #17
  18. nenad

    nenad Guest

    "Jonathan Turkanis" wrote
    >
    > 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.
    nenad, Jan 28, 2004
    #18
  19. nenad

    Rolf Magnus Guest

    nenad wrote:

    > "Jonathan Turkanis" wrote
    >>
    >> 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.


    Adding a language feature always needs to consider two sides. The
    programmer's side and the compiler writer's side.
    Rolf Magnus, Jan 28, 2004
    #19
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Samuel Shulman

    Auto type feature

    Samuel Shulman, May 24, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    433
    Samuel Shulman
    May 25, 2006
  2. coldpizza
    Replies:
    45
    Views:
    906
    coldpizza
    Jan 29, 2008
  3. linkswanted
    Replies:
    1
    Views:
    862
  4. richard
    Replies:
    2
    Views:
    431
    dorayme
    Oct 17, 2008
  5. Jean-Michel Pichavant

    python cmd.Cmd auto complete feature

    Jean-Michel Pichavant, Mar 8, 2011, in forum: Python
    Replies:
    0
    Views:
    289
    Jean-Michel Pichavant
    Mar 8, 2011
Loading...

Share This Page