I don't doubt that one *can* always find or create some sort of
ownership relationship which englobes, directly or indirectly,
all objects. The question is: why? What does it buy you,
except extra complexity and additional effort?
It is all the same benefits of why we have centralized book-keeping in
real life organizations and why everybody always reports (at least on
paper) to someone. Normally everybody does their everyday (quick) work
using horizontal relations between them and their surrounding
colleagues, bosses and subordinates. On exeptional cases like when
there is need for something far or for organization-wide communication
the information will flow following (slow) lines of authority. It is
to lower noise to signal ratio and need to manage too numerous
relations if nothing else.
There will always be some late requirements that are complex to
implement without such supporting structure and also it is hard to
explain (to authors of requirements) what is so tricky about it. Other
case is that it is not as tricky as it needs a new dependency (and
horisontal relation) to be formed between entities that are far from
each other and mostly unrelated. The people with visions and
requirements usually somehow expect such structure behind things even
if they do not explicitly tell it. Some design patterns (like
"visitor", i do not like it really) expect something like hierarchy
and may face problems when it is missing.
No. At a higher level, it has nothing to do with memory
management. It's a question of object lifetime, and the
distinction between value semantics and entity semantics.
Your efforts to give everything an owner.
Oh. Objects in stack have owner. Techinically the object on stack is
owned by member function and member function is owned by whoever is
"this" in it. I do not likely put such temporaries into same lists
with stationary objects. I suspect it is some conflicting idiom about
objects themselves adding themselves into related navigational and
servicing collectives when constructed? With clear hierarchy i do not
need such idioms, owners are decided externally.
That is, quite frankly, ridiculous. The type of an object
pretty much determines its lifetime requirements, and I've yet
to encounter any type which would be used as a local variable
sometimes, and other times be allocated on the stack.
This feels not entirely natural concept. At least some sort of
background information is missing. For example that typical exception-
safety thing is often fine enough (if not it depends a lot on
background):
// this is dynamically allocated T
void T::doSomething()
{
T tmp( *this ); // tmp is T on stack
// ...
// manipulate tmp, fails with throws
// ...
swap( tmp ); // does not throw
}
So "this" there sort of owns its temporary copy that does dangerous
things.
It is even easier to design the application so that every type
has a distinct role and responsibilities, so you don't need to
keep track of storage type.
Sometimes there is difference in roles and responsibilities by object.
For example in Java you have to make different classes for "Type" and
"ImmutableType". In C++ we sometimes do something similar (iterator
and const_iterator), on most typical situations we have "Type*" and
"Type const*". But that goes far from "delete this" and "data
hierarchies" possibly.
[...]
It's a perfectly good (albeit simple) example.
Graph is usually ok example for complex set of relations, i meant the
railway system is maybe too simple subtype of graph and self-
destroying railway line feels too unbelievable concept.
A railway
station knows which lines serve it, and a line knows which
stations it serves. (That's navigation, not ownership.) And
each has to be an observer of the other, so that they can update
the various relationship. Some external events (commands, or
whatever) may affect either the stations or the lines---if the
external event causes one or the other to disappear, it must
notify its observers.
Yes, a line should know between what it is. A station may also have
such direct knowledge about lines. There is also possibility that list
of lines to station is not needed to be cashed into station. If lines
to station are rarely needed then station may ask from his owner,
"railway system" each time what lines service it. On that case it is
also OK if station is not observing the lines.
Note that this is independent of the "delete this" issue.
Depending on how the code is organized, the delete can come from
the object itself ("delete this"), as part of its behavior, or
from the ephemeral event (which because it is ephemeral, can't
really be considered an owner).
For me such "ephemeral event" causing destruction sounds like a
natural disaster.
If t is such it can tell to railroad that it is
now "broken" and to station that it is now "ruins". If the ruins of
stations and broken lines will be removed or repaired can not be
decided by neither event nor object. It may be organized other way but
it feels less natural for me ... so it is like philosophy issue? On
any case i do not feel like doing extra work or adding extra artifical
complexity by maintaining the lists.
If there is a need to find a particular station or line from
some external identifier (name, etc.), then all of the objects
will also be in a map of some sort. But that isn't an owner,
either; it's just a service entity. Typically, it is the
constructor and destructor of the object (station, line) which
inserts and removes the object from such a map.
Yes, for me these "list of stations" and "list of lines" are such
service entities (not necessarily lists in c++ sense)that are allowing
the owner graph "railway system" to get statistics and to find,
extract, add, remove and manage. Railway system therefore takes
responsibility there. It is often hard to squeeze out every such need
from clients of the software early and adding something like that
later sometimes results with duplicate constructs fulfilling
overlapping responsibilities.
Typical example is when someone needs to add some sort of statistics
and then starts to form such a list in wrong place. It is simpler to
realize that it is wrong when there is something else already on
picture with related more universal responsibilities.
