For Programmers: Free Programming Magazines  


Home > Archive > VC Language > January 2006 > can child reference father's member?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author can child reference father's member?
to_be

2006-01-23, 9:57 pm

can I or is it reasonable to reference house::height in chair::IsHeightOk()?

class chair{
int height;
public:
int IsHeightOk(void);
};
class house{
int height;
public:
chair chr;
};

int chair::IsHeightOk(void)
{
}

thank you very much!
to_be


John Carson

2006-01-23, 9:57 pm

"to_be" <honestkid_remove@etang.com> wrote in message
news:%23pzh5zIIGHA.3408@TK2MSFTNGP12.phx.gbl
> can I or is it reasonable to reference house::height in
> chair::IsHeightOk()?
> class chair{
> int height;
> public:
> int IsHeightOk(void);
> };
> class house{
> int height;
> public:
> chair chr;
> };
>
> int chair::IsHeightOk(void)
> {
> }
>
> thank you very much!
> to_be


There is no relationship between the chair class and the house class, so the
answer is no. The fact that the house class has a chair as a member confers
no rights on the chair class with respect to the house class.

In order for the chair class to access a member of the house class, two
things are needed:

1. access rights to the relevant house member.
2. a house object, or a pointer or reference to a house object, that is in
scope for the chair member function.

Access rights as per 1. could be granted by including the declaration

friend class chair;

within the definition of house. Alternatively, you could define the class
chair within the class house instead of making it a free-standing class
(this makes more sense from a design point of view anyway).

The requirements of 2. could be met in many different ways, e.g., chair
could have a member variable that stores a pointer to a house; this pointer
could be initialized in chair's constructor. Alternatively, a pointer or
reference to a house object could be passed as an argument to the function.
An example of this last approach is as follows:

class house{
class chair{
int height;
public:
int IsHeightOk(house const &ht);
};
int height;
public:
chair chr;
};

int house::chair::IsHeightOk(house const &hs)
{
if(height*3 < hs.height)
return 1;
else
return 0;
}


--
John Carson





Igor Tandetnik

2006-01-23, 9:57 pm

"to_be" <honestkid_remove@etang.com> wrote in message
news:%23pzh5zIIGHA.3408@TK2MSFTNGP12.phx.gbl
> can I or is it reasonable to reference house::height in
> chair::IsHeightOk()?
> class chair{
> int height;
> public:
> int IsHeightOk(void);
> };
> class house{
> int height;
> public:
> chair chr;
> };
>
> int chair::IsHeightOk(void)
> {
> }


An instance of chair has no special knowledge of the class it happens to
be a member of. If you want to establish such a relationship, you need
to code it explicitly, e.g. by passing a house* pointer to the chair's
constructor.

In some special cases it may be useful to do something like this:

int chair::IsHeightOk(void)
{
house* h = reinterpret_cast<house*>(
reinterpret_cast<unsigned long>(this) -
offsetof(house, chr)
);
// do something with h pointer
}

This assumes that class chair is only ever used as a chr member of
house.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


Victor Bazarov

2006-01-23, 9:57 pm

to_be wrote:
> can I or is it reasonable to reference house::height in
> chair::IsHeightOk()?
> class chair{
> int height;
> public:
> int IsHeightOk(void);


Do not write 'void'. If the argument list is empty, leave
it empty. There is no need to put something there.

Now, why does this function return 'int'? Shouldn't it
return 'bool'? As in simple 'yes' or 'no' (true/false)?

> };
> class house{
> int height;
> public:
> chair chr;


Why is it public?

> };
>
> int chair::IsHeightOk(void)
> {
> }


In order for 'chr' member in 'house' to access the 'height'
value from the 'house', you need to pass that value to the
'IsHeightOK' function as ah argument. That's the best design
I can think of at the moment:

class chair{
int height;
public:
bool IsHeightOk(int height_of_place);
};
class house{
int height;
public:
chair chr;
};

bool chair::IsHeightOk(int height_of_place)
{
return height_of_place > height;
}

Now, to design your classes properly, you need to begin from
the top and go down. That means you need to design _how_ the
classes are going to be used, first. Then you could fill in
the details by defining what members they are going to have.
You seem to have approached your task from the wrong end.


V


Victor Bazarov

2006-01-23, 9:57 pm

Igor Tandetnik wrote:
> "to_be" <honestkid_remove@etang.com> wrote in message
> news:%23pzh5zIIGHA.3408@TK2MSFTNGP12.phx.gbl
> [..]
> In some special cases it may be useful to do something like this:
>
> int chair::IsHeightOk(void)
> {
> house* h = reinterpret_cast<house*>(
> reinterpret_cast<unsigned long>(this) -
> offsetof(house, chr)


Ahem... Isn't "offsetof" macro reserved for use with PODs only?

> );
> // do something with h pointer
> }
>
> This assumes that class chair is only ever used as a chr member of
> house.



V


Igor Tandetnik

2006-01-23, 9:57 pm

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:u9NCdQJIGHA.1132@TK2MSFTNGP10.phx.gbl
> Igor Tandetnik wrote:
>
> Ahem... Isn't "offsetof" macro reserved for use with PODs only?


Yes, this technique is totally non-portable. I should probably have
mentioned that. It still works most of the time though, at least on VC
compiler. MFC uses it extensively when implementing COM objects. This is
pretty much what I meant by "rare special cases".
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


to_be

2006-01-24, 8:00 am

thank you so much!

I feel that you know much about design principle, could you possibly give me
some URL/recommend me some books about design?

"Victor Bazarov" <v.Abazarov@comAcast.net> 写入消息新闻:e5Y3RPJIGHA.3144@TK2MSFTNGP10.phx.gbl...
> to_be wrote:
>
> Do not write 'void'. If the argument list is empty, leave
> it empty. There is no need to put something there.
>
> Now, why does this function return 'int'? Shouldn't it
> return 'bool'? As in simple 'yes' or 'no' (true/false)?
>
>
> Why is it public?
>
>
> In order for 'chr' member in 'house' to access the 'height'
> value from the 'house', you need to pass that value to the
> 'IsHeightOK' function as ah argument. That's the best design
> I can think of at the moment:
>
> class chair{
> int height;
> public:
> bool IsHeightOk(int height_of_place);
> };
> class house{
> int height;
> public:
> chair chr;
> };
>
> bool chair::IsHeightOk(int height_of_place)
> {
> return height_of_place > height;
> }
>
> Now, to design your classes properly, you need to begin from
> the top and go down. That means you need to design _how_ the
> classes are going to be used, first. Then you could fill in
> the details by defining what members they are going to have.
> You seem to have approached your task from the wrong end.
>
>
> V
>



Ben Voigt

2006-01-26, 7:08 pm

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:e5Y3RPJIGHA.3144@TK2MSFTNGP10.phx.gbl...
> to_be wrote:
>
> Do not write 'void'. If the argument list is empty, leave
> it empty. There is no need to put something there.


arrrgh!

generally
int a(void); is a prototype for a function with no arguments, while
int a(...); is a prototype for a function which may have arguments, the
contents of which are not known, AND
int a(); can mean either of the above depending on compiler and options.

This might not be a big deal for member functions, since they can only be
declared in a C++ header file, but be explicit.

Documentation is another instance where they're not the same.
Use a() to get a widget.
refers to *all* versions of an overloaded function a, while
a(void) assumes a buffer size of 2 kilobytes.
refers to the version with no arguments


red floyd

2006-01-26, 7:08 pm

Ben Voigt wrote:

> generally
> int a(void); is a prototype for a function with no arguments, while
> int a(...); is a prototype for a function which may have arguments, the
> contents of which are not known, AND
> int a(); can mean either of the above depending on compiler and options.


Incorrect. In C89, int a() means there is a function a returning an int
that may or may not take any parameters. In C++, int a() specifically
means no parameters.
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com