Hi,
On Oct 15, 10:11 am, Nick Hounsome <nick.houns...@googlemail.com>
wrote:
On 13 Oct, 19:43, Ismail Pazarbasi <pazarb...@gmail.com> wrote:
[snip]
It looks excessively complicated and confused to me.
Yes, for me as well; fabricated complexity.
For reference counting use shared_ptr (see boost or your compiler).
Yes, my ever first proof of concept used std::tr1::shared_ptr.
I don't understand what you are trying to do with MutableObject. It
seems to me that you are trying to violate const correctness.
MutableObject was intended to lock or unlock an object. That is,
objects (Nodes is Object, and I intend to lock Objects) are const by
default. If caller wants to mutate certain object, it needs to obtain
a non-const pointer/reference, and MutableObject does this; lock the
object, return a pointer (non const). I wanted to control access to
objects and simple (!) locking.
The "normal" way to deal with graphs and const/mutable is to have a
graph class and work primarily through that rather than through the
nodes themselves - that way you don't have to convert a const node to
a mutable one.
I am not experienced in DAG structures, this is a personal, self-
development project (to get intimate knowledge how scene graphs work
by starting from something simple). I thought about locking graph a
few weeks ago. But doesn't it mean working with a coarser granularity?
I thought about locked node count and decided not to do so. Sub-graph
idea is sound. Or, may be I should find a way to introduce locks per-
member; that is, locking "SetName-GetName" or "SetVertices-
GetVertices".
The graph class also removes any need for a factory which is, in any
case, logically dubious - What does it mean to have a node that isn't
in a graph? and hence any desire for unnecessary clutter to prevent
allocating a node. The only downside is that you can't then have
polymorphic nodes but you don't seem to want them anyway.
Factory is to create const objects. I should consider instantiating
nodes directly through Graph or Group class. Thanks for the tip!
I am not really interested in polymorphic nodes. This is too compact:
* Node; just a node, has no children. That is, it's like a leaf node.
* Group; array/list of nodes.
* Drawable; anything that is drawable, and not deriving from Node
I'd like to start with a compact graph, and learn how stuff works
first, but thoroughly, then improve it in time.
If you do want to access a Node* from a const Node* then they way to
do it is to get the non const graph g to do it for you:
Graph g;
const Node* const_n;
...
Node* n = g.Find(const_n);
If the node contains a Graph* then
Node* Graph::Find(const Node* n) // graph is not const
{
if( n->Graph() != this ) throw "a tantrum";
return const_cast<Node*>(n);
}
You also seem to be concerned about concurrent access which is not
usually possible in the most general case for a graph so, again,
either it is best to work through a graph object as this can easily
provide thread safe operations or you probably want to go for some
sort of subtree locking (because it eliminates a lot of deadlock
problems) class using RAII:
{
subtree_lock l(node);
// subtree is locked}
// subtree is unlocked
Hope this helps
--
Subtree idea is sound. Concurrent access may be possible. As a matter
of fact, I thought about traversing this graph, mostly in parallel,
make some optimizations, if possible, and create a scene list (or a
simpler structure) then crerate/use an octree for spatial operations
(e.g. culling).
Thank you very much for the feedback. I may start a proof of concept
code this weekend, without all this fabricated complexity and go for
subgraph locking, if needed.
Ismail
to that same object. Note that my method using graph does not violate
multiple concurrent readers.
subtree locks are naturally deadlock proof. With any finer granularity
multithreaded environment. It can be done but it isn't nice. Of
e.g. The iterator itself can hold a lock either for its lifetime or
[ comp.lang.c++.moderated. First time posters: Do this! ]