Geek Answers Handbook

Pointer to pointer

I have a class with a (not smart) pointer to an interface object (allows pInterface to call it), and I create a nested class that also needs access to this interface. I am going to get around this by passing the interface pointer to the constructor of the nested class as follows:

CNestedClass someClass( pInterface, ... );

However, I am not sure of the best way to store this pointer in a nested class. I could use:

 1) A scoped (or other smart) pointer (to the original object) 2) A pointer to a pointer

What would you guys suggest and why?

EDIT: I have to clarify - the nested class will have to call methods on the interface object, however it does not create it (or modifies the object "pointed" to), the parent class is responsible for this.

+4
source share
5 answers

Using a pointer to a pointer is if a class can change the value of a pointer - for example. deleting an existing object and replacing it with a new one. This allows both classes to still use the same object by dereferencing a pointer to a pointer.

If you are not concerned that the object remains valid throughout the life of both classes.

  • If the nested class lives shorter, you really don't need to worry.
  • If this is the same, if you clean in the correct order (for example, a nested class first, an object later), then again you will not have to worry
  • If the nested class can persist after the owner is destroyed, you must implement a way to ensure that the object is saved.

If you need to ensure the lifetime of the object, this can be done using the semantics of links, either manually or through the interface of a smart pointer.

For a smart pointer, then boost :: shared_ptr would be a good choice. shared_ptr allows you to own an object that is the total number of multiple pointers. When the last shared_ptr goes out of scope, the object is deleted.

(note that this does not apply to auto_ptr, where the object belongs exclusively).

What you need to know

  • When using boost :: shared_ptr, make sure the nested class has a copy for shared_ptr and not a link / pointer.
  • std :: auto_ptr behaves in a completely different way, objects belong exclusively and are not used.
  • boost :: shared_ptr can only work with heap objects, for example, pointers returned from a call to "new"

Example:

 typedef boost::shared_ptr<Interface> shared_interface; class NestedClass { shared_interface mInterface; // empty pointer } void NestedClass::setInterface(shared_interface& foo) { mInterface= foo; // take a copy of foo. } void ParentClass::init( void ) { // mInterface is also declared as shared_interface mInterface = new Interface(); mNestedClass->setInterface(mInterface); }
+6
source

Another reason you can use a pointer to a pointer will be because external code can change the original value of the pointer (for example, make it point to a new object or set it to NULL after releasing the object it points to). However, IMO is a pretty bad practice to change the pointer after giving it to someone else.

So, if neither the external code nor the nested class changes the pointer, just save it in the nested class as a copy of the original pointer as a member variable (field).

+2
source

Go to the address of the pointer to your interface (IMyInterface ** ppInterface) and fill in the pointer if it is implemented by the class.

A class can pass its pointer to this interface and fill in the * ppInterface pointer. If the class does not implement this interface, it can set * ppInterface to NULL.

+1
source

Basically, you share a pointer to the same object between two different objects. If you are not using any smart pointers, just save the pointer to the shared object. You must be careful about owning shared objects, that is, which object is responsible for releasing the shared object and notifies the rest that it has left.

0
source 
 class Outer { class Inner { }; };

Since the Outer object contains only a RAW pointer to the pInterface object, this implies that the external object does not belong or does not have any control over the lifespan of the pInterface object. Therefore, we hope that there is some guarantee that the pInterface will live as long as the external object; In this case, there is no reason even to use a pointer that you could use only a link (provided that there is no situation where pInterface is NULL).

How Inner has its own link (and not a C ++ link) depends on and really we need more information about the relationship between the objects involved!

  • What is the reality between internal and external objects.
  • What is the lifespan of an Inner object relative to the Outer object that it inherited from the pInterface pointer?
  • What is the guarantee that the external object has a shorter lifetime than the pInterface object.

and etc.

0
source

More articles:


All Articles