child list. .

Discussion in 'C++' started by cmk128@hotmail.com, Aug 29, 2006.

  1. Guest

    Hi
    In the following code, when you create a object of class child,
    parent class (class mother) will hold a reference. But i want every
    class derived from mother class has this ability without changing its
    constructor. how to?

    #include <string>
    #include <vector>
    #include <iostream>

    using namespace std;

    class mother{
    private:
    protected:
    vector <void *>list;
    mother(){
    }
    public:
    static mother * getInstance(){
    static mother m;
    return &m;
    }

    vector <void *> * getList(){
    return &list;
    }
    };

    class child : mother{
    public:
    child(){
    cout<<"child()"<<endl;
    mother::getInstance()->getList()->push_back((void *)this);
    cout<<"list->size()="<<(int)mother::getInstance()->getList()->size()<<endl;
    }
    };

    void dumpVector(vector <void *> *v){
    for (int x=0;x<v->size();x++){
    vector <void *>vv=*v;
    int yy=(int)vv[x];
    cout<<(*v)[x]<<endl;
    }
    }

    int main(){
    dumpVector(mother::getInstance()->getList());
    child *c=new child();
    dumpVector(mother::getInstance()->getList());
    return 0;
    }

    thanks
    from Peter ()
     
    , Aug 29, 2006
    #1
    1. Advertising

  2. mlimber Guest

    wrote:
    > Hi
    > In the following code, when you create a object of class child,
    > parent class (class mother) will hold a reference.


    No. Your "child" is also a "mother," so it inherits a "list" member.
    But when you call mother::getInstance(), you are using a distinct
    instance of mother, not the one that is part of the child object. I
    don't think that's what you wanted. Perhaps you intended the "list"
    member to be static instead?

    > But i want every
    > class derived from mother class has this ability without changing its
    > constructor. how to?


    You'll have to clarify what your real intention is before we can say
    for sure. I would also note that void pointers should generally be
    avoided in C++ since they throw away type information that you will
    usually have to add back in at a later point and at your own peril.

    > #include <string>
    > #include <vector>
    > #include <iostream>
    >
    > using namespace std;
    >
    > class mother{
    > private:
    > protected:
    > vector <void *>list;


    Compare
    http://www.parashift.com/c -faq-lite/basics-of-inheritance.html#faq-19.8
    ..

    > mother(){
    > }
    > public:
    > static mother * getInstance(){
    > static mother m;
    > return &m;
    > }
    >
    > vector <void *> * getList(){
    > return &list;
    > }
    > };
    >
    > class child : mother{
    > public:
    > child(){
    > cout<<"child()"<<endl;
    > mother::getInstance()->getList()->push_back((void *)this);
    > cout<<"list->size()="<<(int)mother::getInstance()->getList()->size()<<endl;
    > }
    > };
    >
    > void dumpVector(vector <void *> *v){
    > for (int x=0;x<v->size();x++){
    > vector <void *>vv=*v;
    > int yy=(int)vv[x];


    These lines are never used. The former makes a copy of the vector,
    which could be expensive.

    > cout<<(*v)[x]<<endl;


    This will print an address. Is that what you want?

    > }
    > }
    >
    > int main(){
    > dumpVector(mother::getInstance()->getList());
    > child *c=new child();
    > dumpVector(mother::getInstance()->getList());
    > return 0;
    > }


    You didn't delete c. Of course, the OS will probably reclaim it since
    you're exiting, but it's still good practice to clean up after yourself
    (or better, use a smart pointer, e.g., std::auto_ptr<child>).

    Cheers! --M
     
    mlimber, Aug 29, 2006
    #2
    1. Advertising

  3. Guest

    mlimber 寫é“:

    > wrote:
    > > Hi
    > > In the following code, when you create a object of class child,
    > > parent class (class mother) will hold a reference.

    >
    > No. Your "child" is also a "mother," so it inherits a "list" member.
    > But when you call mother::getInstance(), you are using a distinct
    > instance of mother, not the one that is part of the child object. I
    > don't think that's what you wanted. Perhaps you intended the "list"
    > member to be static instead?
    >
    > > But i want every
    > > class derived from mother class has this ability without changing its
    > > constructor. how to?

    >
    > You'll have to clarify what your real intention is before we can say
    > for sure. I would also note that void pointers should generally be
    > avoided in C++ since they throw away type information that you will
    > usually have to add back in at a later point and at your own peril.
    >
    > > #include <string>
    > > #include <vector>
    > > #include <iostream>
    > >
    > > using namespace std;
    > >
    > > class mother{
    > > private:
    > > protected:
    > > vector <void *>list;

    >
    > Compare
    > http://www.parashift.com/c -faq-lite/basics-of-inheritance.html#faq-19.8
    > .
    >
    > > mother(){
    > > }
    > > public:
    > > static mother * getInstance(){
    > > static mother m;
    > > return &m;
    > > }
    > >
    > > vector <void *> * getList(){
    > > return &list;
    > > }
    > > };
    > >
    > > class child : mother{
    > > public:
    > > child(){
    > > cout<<"child()"<<endl;
    > > mother::getInstance()->getList()->push_back((void *)this);
    > > cout<<"list->size()="<<(int)mother::getInstance()->getList()->size()<<endl;
    > > }
    > > };
    > >
    > > void dumpVector(vector <void *> *v){
    > > for (int x=0;x<v->size();x++){
    > > vector <void *>vv=*v;
    > > int yy=(int)vv[x];

    >
    > These lines are never used. The former makes a copy of the vector,
    > which could be expensive.
    >
    > > cout<<(*v)[x]<<endl;

    >
    > This will print an address. Is that what you want?
    >
    > > }
    > > }
    > >
    > > int main(){
    > > dumpVector(mother::getInstance()->getList());
    > > child *c=new child();
    > > dumpVector(mother::getInstance()->getList());
    > > return 0;
    > > }

    >
    > You didn't delete c. Of course, the OS will probably reclaim it since
    > you're exiting, but it's still good practice to clean up after yourself
    > (or better, use a smart pointer, e.g., std::auto_ptr<child>).
    >
    > Cheers! --M


    What i am going to do is design a graphic framework. Suppose there is a
    GraphicEngine class, it used to response for all the drawing to the
    screen. Also suppose there is a class called Dialog. When user "new
    Dialog()", the GraphicEngine should know it, and able to call
    Dialog::GraphicEngine. That's why the GraphicEngine has to kow how many
    Dialog object is existed and hold its reference (because to call its
    onPaint method).
    thanks
    from Peter ()
     
    , Aug 31, 2006
    #3
  4. mlimber Guest

    wrote:
    > What i am going to do is design a graphic framework. Suppose there is a
    > GraphicEngine class, it used to response for all the drawing to the
    > screen. Also suppose there is a class called Dialog. When user "new
    > Dialog()", the GraphicEngine should know it, and able to call
    > Dialog::GraphicEngine. That's why the GraphicEngine has to kow how many
    > Dialog object is existed and hold its reference (because to call its
    > onPaint method).


    It doesn't sound to me like inheritance is the best representation of
    this relationship (the general rule is to use the weakest relationship
    that you can, cf. FAQ 24.3; inheritance is a strong relationship, while
    relationships such as composition and oberver/callback are weaker). You
    might consider making all drawable classes register with the
    GraphicEngine in their constructors. To do this, either pass an
    instance of GraphicEngine in as a constructor parameter or, if there's
    only ever going to be one instance, make it a global singleton.

    However, we're really getting away from the C++ language proper (the
    topic of this group) and more into general software design. You should
    ask questions on OO software design in another newsgroup such as
    comp.object or similar. Of course, if you need help implementing the
    design in C++, this would be the right group to ask in.

    Cheers! --M
     
    mlimber, Aug 31, 2006
    #4
  5. Guest

    mlimber 寫é“:

    > wrote:
    > > What i am going to do is design a graphic framework. Suppose there is a
    > > GraphicEngine class, it used to response for all the drawing to the
    > > screen. Also suppose there is a class called Dialog. When user "new
    > > Dialog()", the GraphicEngine should know it, and able to call
    > > Dialog::GraphicEngine. That's why the GraphicEngine has to kow how many
    > > Dialog object is existed and hold its reference (because to call its
    > > onPaint method).

    >
    > It doesn't sound to me like inheritance is the best representation of
    > this relationship (the general rule is to use the weakest relationship
    > that you can, cf. FAQ 24.3; inheritance is a strong relationship, while
    > relationships such as composition and oberver/callback are weaker). You
    > might consider making all drawable classes register with the
    > GraphicEngine in their constructors. To do this, either pass an
    > instance of GraphicEngine in as a constructor parameter or, if there's
    > only ever going to be one instance, make it a global singleton.
    >
    > However, we're really getting away from the C++ language proper (the
    > topic of this group) and more into general software design. You should
    > ask questions on OO software design in another newsgroup such as
    > comp.object or similar. Of course, if you need help implementing the
    > design in C++, this would be the right group to ask in.
    >
    > Cheers! --M


    Thank you for your answer
    Your suggestion is same as my original idea, register the class
    itself to GraphicEngine class in the constructor. This is a rule, but
    people may not follow, may be they just forget. So this is not good.
    Let's have a look java, every class extends "Class component" is a
    visual class, the sub-class doesn't need to change anything in the
    construct. This is good design.
    thanks
    from Peter ()
     
    , Sep 1, 2006
    #5
  6. mlimber Guest

    wrote:
    > mlimber 寫é“:
    >
    > > wrote:
    > > > What i am going to do is design a graphic framework. Suppose there is a
    > > > GraphicEngine class, it used to response for all the drawing to the
    > > > screen. Also suppose there is a class called Dialog. When user "new
    > > > Dialog()", the GraphicEngine should know it, and able to call
    > > > Dialog::GraphicEngine. That's why the GraphicEngine has to kow how many
    > > > Dialog object is existed and hold its reference (because to call its
    > > > onPaint method).

    > >
    > > It doesn't sound to me like inheritance is the best representation of
    > > this relationship (the general rule is to use the weakest relationship
    > > that you can, cf. FAQ 24.3; inheritance is a strong relationship, while
    > > relationships such as composition and oberver/callback are weaker). You
    > > might consider making all drawable classes register with the
    > > GraphicEngine in their constructors. To do this, either pass an
    > > instance of GraphicEngine in as a constructor parameter or, if there's
    > > only ever going to be one instance, make it a global singleton.
    > >
    > > However, we're really getting away from the C++ language proper (the
    > > topic of this group) and more into general software design. You should
    > > ask questions on OO software design in another newsgroup such as
    > > comp.object or similar. Of course, if you need help implementing the
    > > design in C++, this would be the right group to ask in.
    > >
    > > Cheers! --M

    >
    > Thank you for your answer
    > Your suggestion is same as my original idea, register the class
    > itself to GraphicEngine class in the constructor. This is a rule, but
    > people may not follow, may be they just forget. So this is not good.
    > Let's have a look java, every class extends "Class component" is a
    > visual class, the sub-class doesn't need to change anything in the
    > construct. This is good design.


    So create an abstract base class that all drawable objects inherit from
    and have its constructor do the registration with the same technique I
    described in my previous post. You should not inherit from the object
    that you're registering with (in your case GraphicEngine), however.

    Cheers! --M
     
    mlimber, Sep 1, 2006
    #6
    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. bhchng
    Replies:
    0
    Views:
    669
    bhchng
    Jan 13, 2004
  2. davout
    Replies:
    0
    Views:
    562
    davout
    Apr 18, 2004
  3. leon
    Replies:
    0
    Views:
    439
  4. Bryan Ax
    Replies:
    6
    Views:
    555
    Peter Flynn
    May 17, 2006
  5. Jeff Rodriguez
    Replies:
    23
    Views:
    1,157
    David Schwartz
    Dec 9, 2003
Loading...

Share This Page