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".
–
David ThornleyJan 12 '11 at 16:40

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.

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".

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.
–
Stefano BoriniJan 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 WheelerJan 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 BoriniJan 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 WheelerJan 12 '11 at 18:51

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.

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.

he actually didn't specify what language he was using until jeff responded.
–
PemdasJan 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 ThornleyJan 13 '11 at 15:08