copy construct

[cilu]

Messing up with references is pretty simple. If we are going back to Scott Meyers, Chapter 1 from More Effective C++ should be clear enought:

First, recognize that there is no such thing as a null reference. A reference must always refer to some object. As a result, if you have a variable whose purpose is to refer to another object, but it is possible that there might not be an object to refer to, you should make the variable a pointer, because then you can set it to null. On the other hand, if the variable must always refer to an object, i.e., if your design does not allow for the possibility that the variable is null, you should probably make the variable a reference.

References, then, are the feature of choice when you know you have something to refer to, when you'll never want to refer to anything else, and when implementing operators whose syntactic requirements make the use of pointers undesirable. In all other cases, stick with pointers.

[ovidiucucu]

CFu *p = new CFu();
CFuFu &r = p->GetFuFu();
delete p;
// r is now invalid

Well, nomore contradicting Scott Meyers, but just a note:
The above code demonstrates that if somebody really wants to do something bad, then for sure can do it.
Even much more natural is just to write...

   CFu fu;
   CFufu& rFufu = fu.GetFufu();
   // use rFufu without headaches!

...why make it easier and safer since it can be made complicated and dangerous?

[cilu]

Yes, but there are so many cases (pointless to give one), when

CFu fu;
CFufu& rFufu = fu.GetFufu();
// use rFufu without headaches!

just can't be used, thus

CFu *p = new CFu();
CFuFu &r = p->GetFuFu();
delete p;
// r is now invalid

is the only solution. And then you have to be very careful with those references...

[ovidiucucu]

Yes, but there are so many cases (pointless to give one), when

CFu fu;
CFufu& rFufu = fu.GetFufu();
// use rFufu without headaches!

just can't be used, thus

CFu *p = new CFu();
CFuFu &r = p->GetFuFu();
delete p;
// r is now invalid

is the only solution. And then you have to be very careful with those references...

IMHO: nothing is pointless. Please, just give one.

EDIT: Usually, I am very careful with those references.
But I think, instead of learn by heart some rules, it's better to discuss them.
This one may be an interesting subject.

[TheCPUWizard]

Of course any one can do bad things, but you can make it more difficult for them to do so.


Just a note: this whole disucssion is outside the original posters issue, since his can be solved by only exposing the CPen as a protected object, therefore it will only be available to derived classes which can not exist pas the point of the base class.


note: Cilu's post on when to use pointers, I completely agree with, but in this case changing the reference to a pointer does nothing to help the problem wince the desctruction of the owning object has no was to set any existing pointers which refer to its members to null

The simplest way to handle this is by using RCO's [reference counded objects]. There are two common patterns.

1) Have the containing class dynamically allocate the contained class so that it can exist longer than the container. [It would self destruct when its reference count goes to 0.

2) Have the container class be "bound into existance" by the contained class. This would have the effect of the contained object keeping an outstanding reference to the outter object. This is a more difficult pattern to implement, but is necessary in some cases.

If you ar going to use reference counting (or another object management paradigm) it is a good idea to be consistant and dynamically allocate all of your objects. While this takes a few more keystrokes, it gives provides a number of benefits.

Readers should recognize the information in this post as being exteremely similar to the techniques used by COM.

[marsh_pottaye]

Just a note: this whole disucssion is outside the original posters issue, since his can be solved by only exposing the CPen as a protected object, therefore it will only be available to derived classes which can not exist pas the point of the base class.

... as somebody already said.

Declaring private members in base class and accessing them in derived classes throught public metods it's like
scratching yourself on the right side of head using the left hand.
Just declare them as protected, is there a problem for you to do this?

However, you cannot blame us, as long as this new direction is opened by yourself:

I have to disagree with ovidiucucu on this one. Returning a reference to an internal (aggregated) item is risky when there is no object managment involved.

If CFigure object goes out of scope, then the CPen object will be destroyed also. However there may be outstanding references (via ovidiucucu's suggestion). This will most likely lead to a crash or other undefined behaviour.

Scott Meyers has a full chapter (#23) devoted to this subject if you are looking for an indepth discussion.

Anyhow, I agree with this point of view:

IMHO: nothing is pointless.
...................................................................
I think, instead of learn by heart some rules, it's better to discuss them.
This one may be an interesting subject.

[TheCPUWizard]

Thanks for the comments. I personally believe that it is a good thing when threads discuss why various solutiions are not ideal. This is good even if a better solution has already been found. All too often people see one method of doing something and then ask "why didn'y they......". By covering alternatives this can be addrssed up front.

Also the various FAQS and many articles are distilled from topics that involve alot of discussion. This is one of the biggest [IMHO] benefits of forums such as this.

[cilu]

IMHO: nothing is pointless. Please, just give one.

OK: when it comes to class hierarchies pointers are the beter choise.

I don't see how you can use

CFu fu;
// do something with fu

when fu is supposed to be a Decorator or part of a Strategy, etc.

As for going out of the topic, sometimes that happens and discussions like this one are very wellcomed IMHO.