Posted by William D McQuain on March 19, 2001 at 07:50:39:
In Reply to: Array Container posted by Leon Gunden on March 17, 2001 at 12:08:25:
: I already had the array class designed, when McQuain threw a curve ball on friday in class. I have always thought of containers as truly containing the data they hold.
Hold, yes. Own, questionable.
Whether this is logical or physical containment is inconsequential, the point is that a container should be responsible for the data it holds (hence it should both create and destroy it).
I don't think so. Certainly a container will not normally CREATE the data, although it may copy a data element that was created by its client.
The other day McQuain introduced this concept as one of association between the container and the data. Though this does make some sense now that I think about it, it introduces some implementation complexity which McQuain did not mention in class. For instance, he said that any data left in the container at the point of the container's destruction should be destroyed by the container.
Unless the client is keeping pointers to those data elements then they will never be deallocated unless the container destructor manages it.
His argument for this was good (i.e., "there is a good change that if it doesn't there will be a memory leak"), however are we going to restrict the container class so that it cannot be passed by value?
If it were passed by value the formal parameter would destroy all of the contained data when the function returns, leaving the actual parameter with a whole container full of dangling pointers.
Again, certainly not... unless the container is not implemented to support deep copy when passed or returned or assigned. This is simply not a logical issue. A properly implemented container will not suffer this problem.
Perhaps the container should not be responsible for destroying any of its data, and this should be left as the users responsibility
How can the client be responsible for destroying data that wasn't previously removed from the container and returned to the client?
My point was that any data left in the container when its destructor fires cannot ever be returned to the client... so that data must be cleaned up by the container's destructor or it never will be.
(but then we are giving up the benefit of the constructor/destructor sequence and we might as well be writing in C). This idea seems to introduce an extreme amount of complexity on the user of the container class since he/she must understand these issues and refrain from using pass by value, etc. Also when a multiplicity of container objects are in the same scope, each containing links to the same data,
That scenario should never arise. If it does, it is the fault of the client for stupidly creating aliases that the container cannot, in principle, be aware of.
a simple remove operation becomes quite a nightmare (as each container must in turn remove the data, or risk a dangling pointer). In short, this idea makes sense when McQuain says it in class, but it seems to me to be impractical. Not to mention that it introduces some subtle encapsulation violations (how can the container guarantee a sorted sequence when the user of the container may have direct links (pointers) to the data that the container is organizing?, etc, etc).
The container cannot guarantee that. The container can guarantee that if the client uses the container sensibly, as intended, then the data will be correctly maintained. The scenario you're describing also arises as long as the client can possess a pointer to the container itself, not just to the data it holds.
The protections afforded in C++ are, at most, against careless errors, not against malicious misuse. (And sometimes, stupidity rises to the level of malice.)
Perhaps I am missing something obvious here, but this assumption that a container is merely associated with its data seems to lead to a number of quite serious flaws (at least one of which has been ground into our heads many times as a test question, i.e. "the shallow copy problem"). Is this the correct way to model containment? (sorry to write a book here, but these questions are keeping me from completing my program design)
Post a Followup