shallow copy with pointers

[acorn]

if you assign a pointer to a class member from outside the class and the memory management is dealt with outside the class does that mean a shallow copy is ok? it seems to work.

#include <iostream>
#include <string>
using namespace std;

class teacher
{
public:
	teacher(string name) : teachername(name) {}
	string getname() {return teachername; }

private:
	string teachername;
};

class school
{
public:
	school(teacher *teach = 0) : mteach(teach) {}
	string getteacher() { return mteach->getname(); }

private:
	teacher *mteach;
};


int main(int arc, char *argv[])
{
	teacher *teach = new teacher("Mr Mooney");
	school sch(teach);
	cout << sch.getteacher() << endl;

	school myschool(sch);

	cout << myschool.getteacher() << endl;

	delete teach;


	cout << endl;
	cout << "Press ENTER to continue...";
	cin.ignore(numeric_limits<streamsize>::max(), '\n' );
}

[m4ster r0shi]

I guess this is an example where this behaviour is not only acceptable but also desirable.

[shacktar]

the memory management is dealt with outside the class does that mean a shallow copy is ok?

This works if you're careful. In your example, you would be dereferencing a null pointer if you call myschool.getteacher() after the call to delete teach;. What I would recommend is after deleting teach, set it to zero (null pointer) and have your school class check if mteach is not null before dereferencing it.

[Disch]

What I would recommend is after deleting teach, set it to zero (null pointer) and have your school class check if mteach is not null before dereferencing it.

setting teach (in main) to 0 will not change mteach (in school) to 0. They're two separate pointers.

[shacktar]

Oh yeah, whoops.

I also didn't notice this:

school myschool(sch);

That means two instances of school (myschool and sch) could potentially dereference a null pointer after teach is deleted. You can see how dealing with memory management outside of a class can get pretty hairy rather quickly. Just a word of caution.

[acorn]

thanks for the reply. I thought the post just dropped off the edge of the web.

Yes there is another problem if you call getteacher from school without first assigning a teacher it will atttempt to use a invalid pointer as well. the example is far from complete. it was taken from an example of something else and modified. Im learning copy constructors and assignment operators and this kinda helped with my understanding a little more. I wasnt sure if I would have to create a copy constructor for every single case I was using a pointer in a class or make it private. I didnt think so but I wanted to be sure.

I have seen in mfc classes people not implement a copy constructor nor make it private when using new and delete. Im not sure if thats just pure laziness or if its just common to hope people wont use the class in that way. i was just peaking at mfc i dont really know it well.

[chipp]

school(teacher *teach = 0)

wasn't that mean to set the teach parameter to 0 (zero)?

[acorn]

yes so i could test some things. but it still crashed when i called it. im not sure why. i thought if the pointer was 0 or null it wouldnt crash. i also tried checking first if it was null or 0 and to only call it if it wasnt null and it still crashed. so i dont know what i did. i had a longer more complete version as i played with it but it was something i wasnt going to keep so i deleted it.

[shacktar]

I see the following cases working when dynamic memory is handled outside a particular class:

1. Implementation of the Singleton design pattern.

e.g. Say you're implementing a 3D game engine, and you have one (and only one) instance of a camera object. This camera instance is created at the beginning of the game, exists at any point during the usual running of the game, and is destroyed at the end. The main draw loop will use the camera instance, of course to figure out where the player is and draw the game entities from the current point of view.

If a particular class makes extensive use of the camera, it may be more efficient for it to store a pointer to the instance. Since this class does not "own" the camera, it would simply shallow copy the camera instance during assignment (and copy constructing). This camera instance pointer will also not be deleted in this class' destructor. This is OK, since it's up to someone else to destroy it. Since we made the assumption that the camera will exist at any point during the usual running of the game, we can feel safe derefering the pointer, etc. within this class without any catastrophic consequences.

2. "Parent-Child" relationships

e.g. Say you're creating a program that implements the Windows Explorer search functionality. You will have a GUI that allows the user to input search terms and it will have a pane that gets updated with the file results. You encapsulate the file searching in a "Searcher" class which adds the file results to a queue which the GUI can access. The Searcher class instantiates a non-copyable object called "FileWalker" which does all the file I/O in a seperate thread (to not bog down the GUI). A FileWalker object gets created, searches a bunch of directories/files and deletes itself upon completion.

For matters of design, you want the GUI to know the interface of Searcher and you want the FileWalker to interface only with the Searcher (and you want the FileWalker to not have knowledge of the queue that the GUI will access). In this case, it may be pertinent to give the FileWalker a pointer to the Searcher class. When the FileWalker has found a file matching the search terms provided to it by the Searcher, it can use this pointer to notify the Searcher (which would then place the file path onto the queue). When a FileWalker is destroyed, it would not delete the Searcher pointer because Searcher is a parent of FileWalker and thus a FileWalker cannot exist without a Searcher to breed it. By the same token, a FileWalker can dereference a Searcher pointer without worries. The FileWalker class is non-copyable so we wouldn't be making a copy constructor or overloading the assignment operator.

There are many other cases but these are just some examples. It basically comes down to ownership and lifetime of the dynamic memory.

If the memory belongs to some other class, then shallow copying it in the copy constructor/overloaded assignment is OK. If it is the only dynamic memory of this class (again, this memory is owned by another class) then you don't need to provide a copy constructor/overloaded assignment for this class.

You also need to be sure that the memory will be there when your object is instantiated, and that it would still be there right up to the time your object goes out of scope. That is, the lifetime of the object should be contained within the lifetime of the dynamic memory in question.

[Disch]

e.g. Say you're implementing a 3D game engine, and you have one (and only one) instance of a camera object.

I just had to chime in and say that such a situation is a very poor use of a Singleton. It's entirely possible (and rather likely) to have multiple cameras (say, one for each viewport).

Especially if your objects will have a pointer to a camera in them.. there's absolutely no reason to make it a singleton.

Somewhat off topic, I know, but since Singletons are so often misused I felt obligated to chime in. =P

[acorn]

thanks for the info guys. I appreciate that you took the time to explain. now I know why this site is the best.

[chipp]

yes so i could test some things. but it still crashed when i called it. im not sure why. i thought if the pointer was 0 or null it wouldnt crash. i also tried checking first if it was null or 0 and to only call it if it wasnt null and it still crashed. so i dont know what i did. i had a longer more complete version as i played with it but it was something i wasnt going to keep so i deleted it.

it doesn't crashed. fine with me. but, i don't understand, if the parameter is NULL / 0 then how could you point to the right address?

[shacktar]

Setting a pointer to 0/NULL makes it so double deletion doesn't occur.

You can also use the fact that a pointer is set to NULL to check before deleting it.

int* intPtr = new int;
*intPtr = 42;
//...
delete intPtr;
intPtr = 0;
//...
#ifdef BEING_LAZY
     delete intPtr; //intPtr is null, so this won't cause a problem
#else
     if(intPtr)
     {
          delete intPtr;
          intPtr = 0;
     }
#endif 

[Disch]

checking if a pointer is null before deleting it is redundant, though, because delete already does that. Deleting a null pointer has no effect.

#ifdef BEING_REDUNDANT
if(intPtr)
{
    delete intPtr;
    intPtr = 0;
}
#else
delete intPtr;
intPtr = 0;
#endif 

[chipp]

yes, but how the pointer still pointing to the right address in fact you set it to 0?

[Disch]

It doesn't point to the right address after that. That's kind of the point.

Once you do delete intPtr;, the int that intPtr pointed to no longer exists, so intPtr becomes a bad pointer. Trying to dereference the pointer after you delete would be "very bad".

Setting it to 0 makes it obvious that the pointer is invalid, and prevents it from being mistakenly deleted again.

[chipp]

do you mean this code:

int* intPtr = new int;
*intPtr = 42;
//...
delete intPtr;
intPtr = 0;
//...
#ifdef BEING_LAZY
     delete intPtr; //intPtr is null, so this won't cause a problem
#else
     if(intPtr)
     {
          delete intPtr;
          intPtr = 0;
     }
#endif  

or this code:

school(teacher *teach = 0) : mteach(teach) {}

because, i mean the 2nd code...

[acorn]

school(teacher *teach = 0) : mteach(teach) {}

0 is just a default param which means there hasnt been a teacher assigned to the school yet. so you can construct school without a teacher object. when you construct it properly using a teacher object the default 0 param isnt used. otherwise I dont understand what your asking.

[chipp]

oh, so that's how the default works. i just know it. i thought you always assign it to 0 :)

btw: does my words confusing?