Re: delete this; (Was: std::string name4 = name4;)
On Aug 13, 12:53 am, =D6=F6 Tiib <oot...@hot.ee> wrote:
On 12 aug, 21:51, James Kanze <james.ka...@gmail.com> wrote:
On Aug 12, 5:01 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On Aug 12, 12:57 pm, James Kanze <james.ka...@gmail.com> wrote:
Application logic is later needing it there. "Collective" or
"population" are just examples, there is usually something
with more finesse needed like "collective in location".
I've never found this to be the case. Unless such
a "collective" solves a real problem, its introduction is
artificial and adds unnecessary complexity.
Usually it solves a real problem. For extending example of
"collective in location": Various effects are location-local
(like thread-local?). You do not need to build separate
messaging, signaling, observing system into each of objects to
tell to whole population in a location about such effects for
example. Instead you can tell it to "collective in location".
And then? This artificial "collective in location" doesn't
really need to know; other objects may or may not need to know.
Or does the "collective in location" notify all of the other
objects in it? This seems a bit strange to me: perhaps some of
the interested objects are in a different "collective in
location", and most of the objects in the "collective in
location" are probably not interested.
Bad design is always possible. Lets just imagine that i put effort
into avoiding making hierarchy that supports telling to all idle
baker's to fix more shoes? I believe that there always exists at least
one good hierarchy that supports the goals of software. Same
functionality is possible to achieve with multiple ways so ... i can
not argue here.
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?
Presence of ownership (more properly whole/part hierarchy) ma=
kes
things like dumping full state of everything, saving and rest=
oring
situations simpler.
For some definition of "everything"?
Yes it is that everything that is relevant for something. How can=
it
be they are not needed to be saved/dumped/serialized? In context =
of
what they are serialized when they are?
When do you ever serialize the entire application?
Almost never. That is the point. Tree-like hierarchy helps me to
simplify and to sort out what is a minimal "whole" set that has to be
serialized.
The "whole" set which needs to be serialized is the set of
objects modified in the transaction (if the serialization is for
persistency), or the objects which should be returned from the
request (if the serialization is for data transfer)---in the
latter case, it's entirely possible that some of the objects are
on the stack.
Yes. Static, dynamic and automatic storages are there in C++
for allowing to optimize memory management.
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.
Why you brought objects on stack into a discussion about
"delete this"?
Your efforts to give everything an owner.
This is another (subtle) problem, average novice may fail to
guard such suicidal objects from being in the stack.
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.
It is somewhat easier to keep track about storage type under
instances (of same class) by some external book-keeper.
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.
[...]
Ok. Lets say i need a complex multidirectional graph.
I implement it on base of vertexes list and nodes list. For me
such underlying simple structure helps to implement and verify
and serialize and test that complex structure of graph and
algorithms on it. Now ... how such underlying tree-like
structure ("graph" -> "node list" -> "nodes" and "graph" ->
"vertex list" -> "vertex") makes something more complex? On
the contrary, the nodes and vertexes lists are maybe not
naturally there but for me they make everything simpler and
more robust.
What role do the node list and vertex list play in the
application? I've not done a lot of work with graphs, but in
general, the graph itself contains the nodes.
Graph, nodes and vertexes are just abstract words. You said that a
tree is too trivial so i did bring graph as example how a graph is
technically implementable as tree with two branches. As example for an
imaginary application node lets take "Station" and vertex "Railway".
Node list is "list of railroad stations" and vertex list is "list of
railways".
Situation that the hierarchy is missing: No artifical "Railway System"
graph is present, it was not explicitly required. Just Stations, the
Objects. If Station discovers that all railway coming and going from
it are removed then ... "delete this"? Maybe you can give better
example, lack of owning objects based on such example is outright
egregious.
It's a perfectly good (albeit simple) example. 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.
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).
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.
--
James Kanze