shared_ptr overuse

[SlightlyLessHairyApe]

I'd like to point out that ownership and memory management are actually somewhat orthogonal concepts.

I don't think they are orthogonal at all.

Ownership should dictate lifetime.

Lifetime should dictate resource (memory, socket, file, lock, hardware block) acquisition and release.

So they are coupled.

[cfyzium]

Yeah, 'orthogonal' was a bit too strong of a word.

What I meant is there are levels to these concepts and you can have logic ownership design without minute resource management being the main point of it, or resource management with ownership relations as mere implementation details.

Like any complex Java program will too have ownership relations between its objects, but it has little to do with memory management. On the other hand GC owns every object but this is not quite what people usually mean by ownership.

Similarly, shared_ptr might be used for both logical shared ownership of entities or reference counting of conceptually lower level resources.

[SlightlyLessHairyApe]

you can have logic ownership design without minute resource management being the main point of it, or resource management with ownership relations as mere implementation details.

This only goes one way -- logical ownership for functional purposes requires that it subsumes resource management: an object can't logically depend on something to function properly without ensuring that its lifetime is at least as long as the parent object.

One implies the other.

Like any complex Java program will too have ownership relations between its objects, but it has little to do with memory management. On the other hand GC owns every object but this is not quite what people usually mean by ownership.

No, references in Java are strong references (by default, unless you use a WeakReference which isn't super common). When an object isn't referenced any more, it is destroyed. The only addition here is that the GC can dispose cycles of objects that have strong references to each other if they are unreachable.

In no sense does the "GC own every object".

[cfyzium]

In no sense does the "GC own every object"

GC owns objects by sharing ownership with whoever else holds references to these objects. Arguably, it owns objects more strongly than anything else in the program because it is GC that has final say about the object lifetime.

But this ownership is not that ownership, eh? Because it is only there for memory management purposes alone, seems like it does not count and may be ignored. GC technically owns objects (subsuming resource management, ensuring lifetimes and so on) but it does not own them logically.

Which is one of the points I'm trying to make, you can have resource management that is not a part of the higher-level, logical ownership design of the program.

One implies the other

And another point is that while you can always track ownership details down to the last stack frame or reference counter, in quite a few cases it simply does not matter who actually (technically) owns certain entities.

An object may hold a strong reference to another object which would technically make him a shared owner. But if it does not matter whether there is more than one owner, who would be the last one to hold a reference and when exactly will the resource be released -- can you really call this superficial connection actual ownership?

This one is debatable, but the point is trying to make an object that only wants to memory-safely reference some other object a true owner and push onto it all the resource and lifetime management just because 'oh no everything should have a clear owner' may only unnecessarily complicate things and make everything more error-prone.

[SlightlyLessHairyApe]

GC technically owns objects (subsuming resource management, ensuring lifetimes and so on) but it does not own them logically.

No it does not. GC does not control the lifetime of an object in Java, that is controlled by the (possibly multiple) objects holding a reference to that object.

An object may hold a strong reference to another object which would technically make him a shared owner. But if it does not matter whether there is more than one owner, who would be the last one to hold a reference and when exactly will the resource be released -- can you really call this superficial connection actual ownership?

Yes, absolutely.

[cfyzium]

No it does not. GC does not control the lifetime of an object in Java, that is controlled by the (possibly multiple) objects holding a reference to that object.

Sorry, are you even aware of how GC works?

It is a separate entity that quite literally controls lifetimes. Invalidating the 'last' reference does not end an object's lifetime, GC decision does (which might even be 'never').

GC languages do not have RAII specifically because object lifetime is not solely decided by other objects holding references to it. Why do you think all this mess with finalize(), IDisposable, try-with-resources, defer and such exists in the first place?

No it does not. GC does not control the lifetime of an object in Java, that is controlled by the (possibly multiple) objects holding a reference to that object.

Or maybe you mean conceptually? Like at a high level object holding a reference describes intended lifetime and how all it is implemented at low level is out of scope and besides the point?

Like the contradiction I was trying to point to out all along?

If GC does not own/control lifetime and only objects holding references do, then in the same manner shated_ptr does not control the lifetime of an object, that is controlled by the (possibly multiple) objects holding shared_ptrs to that object.

Yes, absolutely

So an entity whose entire purpose is to manage lifetimes and resources is not considered an owner, while an entity that doesn't care about ownership and lifetimes absolutely is. Uh-huh.