3

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 ?

Improve this question
2
  • 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". – David Thornley Jan 12 '11 at 16:40
  • 2
    @David Ownership = the object responsible for deletion – Stefano Borini Jan 12 '11 at 16:55
3

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.

Improve this answer
4
  • 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. – Stefano Borini Jan 12 '11 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. – Mason Wheeler Jan 12 '11 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. – Stefano Borini Jan 12 '11 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. – Mason Wheeler Jan 12 '11 at 18:51
1

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.

Improve this answer
8
  • 2
    I'm using a non memory-managed language. – Stefano Borini Jan 12 '11 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 Jan 12 '11 at 16:42
  • @Jeff : Fortran 90 – Stefano Borini Jan 12 '11 at 16:55
  • 1
    he actually didn't specify what language he was using until jeff responded. – Pemdas Jan 12 '11 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. – David Thornley Jan 13 '11 at 15:08
1

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.

Improve this answer
1

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.

Improve this answer
0

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

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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