In some libraries I've seen, a lot of emphasis is put into change of ownership of pointers, like for example a class method that allocates and returns a pointer to an object while relinquishing its ownership to the caller.

My question is: how would you design if you had to code something with the constraint that no pointer ownership gets transferred, ever ?

  • What do you mean by ownership? Meanings that pop to mind include "I'm responsible for deleting the memory", "I can change this object without messing up another routine", and "I can rely on this object not being changed by anything else". Commented Jan 12, 2011 at 16:40
  • 2
    @David Ownership = the object responsible for deletion Commented Jan 12, 2011 at 16:55

5 Answers 5


If you want to be sure that pointer ownership never gets transferred, you have to ensure that each object has an owner from your library. This can be done in two ways.

  1. When you create your objects, the constructor should take a reference to another object that will be its owner, and then add itself to the owner's "child list".
  2. You don't create the objects yourself; instead you ask the owner to create a new child, which it adds to its list.

Either way, this can restrict your ability to delete objects when they're no longer needed but their parent object is. To get around this, put a line in the destructor that removes the object being destroyed from its parent's list.

  • the first option basically transfers the ownership, which is not possible within my constraints. It's the caller that relinquish it to the callee (in this case, the constructor). The second option is what I am doing right now, but it introduces some consequences I am still thinking through. Commented Jan 12, 2011 at 18:28
  • @Stefano: Is this a technical issue or a matter of interpretation? I'm not sure how it works in Fortran 90 (or if there even are objects) but I don't consider an object to truly belong to anything before the constructor exits. So if ownership is set within the constructor, then it's always been that way and nothing's been transferred. Commented Jan 12, 2011 at 18:31
  • F90 does not have OOP, but you can code OOP-style, with a lot of limitations, of course. Ownership is a matter of agreement (means, who is in charge of deleting the object), although in some cases, and in general, the choice is straightforward. I misunderstood your first option, and indeed I now see how this would work. Commented Jan 12, 2011 at 18:49
  • @Stefano: Glad I could help. This model is basically copied directly from the way Delphi handles GUI objects, and it works well enough that most coders never have to worry about ownership at all. Commented Jan 12, 2011 at 18:51

What your asking for is exactly what JAVA or .NET do, which is track memory memory usage. It is done such that the caller of a library function does not explicitly take ownership of the pointer.

  • 2
    I'm using a non memory-managed language. Commented Jan 12, 2011 at 16:38
  • 1
    are you using C++? or something similar. If so then you would want to look at smart pointers which provide reference counting of pointer objects.
    – Jeff
    Commented Jan 12, 2011 at 16:42
  • @Jeff : Fortran 90 Commented Jan 12, 2011 at 16:55
  • 1
    he actually didn't specify what language he was using until jeff responded.
    – Pemdas
    Commented Jan 12, 2011 at 17:34
  • 1
    @Mason: Particularly his comment in answer to mine that ownership means responsibility for deletion. In a GC language, the system always has ownership in that sense. Commented Jan 13, 2011 at 15:08

I'm a Delphi programmer and I think we can solve a lot of this with the use of BPL's but never have explored it since it's easier to just write a free whatever function than integrate yet another way of doing things.

That being said, depending on the way things are owned or created in your language, it might be easier to do some sort of messaging between DLL's with strings of ascii (i.e. XML/JSON) or binary data (serialize your objects somehow) and recreate them on the other side.


I wouldn't. That restriction would preclude just about every useful reason to have pointers at all! Factory functions, for example, would be out. Any time you saw a black diamond on the other side of an abstraction...you'd be screwed.


Whoever allocates something is (or should be) responsible of destroying it when obsolete, if we're talking about pointers to dynamically allocated objects.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.