child list. .

[cmk128]

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::getInst ance()->getList()->push_back((voi d *)this);
cout<<"list->size()="<<(int )mother::getIns tance()->getList()->size()<<endl ;
}
};

void dumpVector(vect or <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(moth er::getInstance ()->getList());
child *c=new child();
dumpVector(moth er::getInstance ()->getList());
return 0;
}

thanks
from Peter (cm****@hotmail .com)

[mlimber]

cm****@hotmail. com 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::getInst ance(), 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-lit....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::getInst ance()->getList()->push_back((voi d *)this);
cout<<"list->size()="<<(int )mother::getIns tance()->getList()->size()<<endl ;
}
};

void dumpVector(vect or <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(moth er::getInstance ()->getList());
child *c=new child();
dumpVector(moth er::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<c hild>).

Cheers! --M

[cmk128]

mlimber 寫�：

cm****@hotmail. com 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::getInst ance(), 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-lit....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::getInst ance()->getList()->push_back((voi d *)this);
cout<<"list->size()="<<(int )mother::getIns tance()->getList()->size()<<endl ;
}
};

void dumpVector(vect or <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(moth er::getInstance ()->getList());
child *c=new child();
dumpVector(moth er::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<c hild>).

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::Graphic Engine. 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 (cm****@hotmail .com)

[mlimber]

cm****@hotmail. com 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::Graphic Engine. 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

[cmk128]

mlimber 寫�：

cm****@hotmail. com 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::Graphic Engine. 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 (cm****@hotmail .com)

[mlimber]

cm****@hotmail. com wrote:

mlimber 寫�：

cm****@hotmail. com wrote:

What i am going to do is design a graphic framework. Suppose there isa
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::Graphic Engine. 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