From 8f8831c8b3c4906c171237efeb21ab93d335c354 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 9 May 2009 17:32:29 +0200 Subject: [PATCH] planning index structure.. --- src/lib/accesscasted.hpp | 4 ++-- src/lib/variant.hpp | 12 ++++++------ src/lib/wrapperptr.hpp | 6 +++--- src/proc/mobject/placement-index.hpp | 12 ++++++------ src/proc/mobject/placement-ref.hpp | 10 +++++++++- tests/lib/factoryspecialtest.cpp | 4 ++-- wiki/renderengine.html | 25 ++++++++++++++++++++++--- 7 files changed, 50 insertions(+), 23 deletions(-) diff --git a/src/lib/accesscasted.hpp b/src/lib/accesscasted.hpp index 58f2e2dbc..b6832f37f 100644 --- a/src/lib/accesscasted.hpp +++ b/src/lib/accesscasted.hpp @@ -27,10 +27,10 @@ ** and the target type (type we need within the usage context). ** When instantiating AcessCasted, we get a template static function ** \c AcessCasted::access(SRC& elm), but the actual implementation - ** is choosed using boost::type_traits. If no viable implementatino can be + ** is chosen using boost::type_traits. If no viable implementation can be ** selected, \c EmptyVal::create() is invoked instead, which by default ** creates a NULL value or similar by using the no-argument ctor of the - ** type TAR. Alternatively, you may define an specialisation fo EmptyVal, + ** type TAR. Alternatively, you may define an specialisation of EmptyVal, ** e.g. throwing an exception instead of creating a NULL value. ** ** @see lumiera::WrapperPtr usage example to access a variant record diff --git a/src/lib/variant.hpp b/src/lib/variant.hpp index 15002b7f8..3f9cea028 100644 --- a/src/lib/variant.hpp +++ b/src/lib/variant.hpp @@ -24,7 +24,7 @@ /** @file variant.hpp ** This file defines a simple alternative to boost::variant. ** It pulls in fewer headers and has a shorter code path, but also - ** doesn't deal with alignement issues and is not threadsafe. + ** doesn't deal with alignment issues and is not threadsafe. ** ** Values can be stored using \c operator= . In order to access the value ** stored in lumiera::Variant, you additionally need to define a "functor" @@ -58,7 +58,7 @@ namespace lumiera { /** * internal helper used to build a variant storage wrapper. - * Parametrized with a collection of types, it provides functionality + * Parametrised with a collection of types, it provides functionality * to copy a value of one of these types into an internal buffer, while * remembering which of these types was used to place this copy. * The value can be later on extracted using a visitation like mechanism, @@ -214,10 +214,10 @@ namespace lumiera { * This utility class is similar to boost::variant and indeed was implemented * (5/08) in an effort to replace the latter in a draft solution for the problem * of typesafe access to the correct wrapper class from within some builder tool. - * Well -- after finisihng this "exercise" I must admit that it is not really + * Well -- after finishing this "exercise" I must admit that it is not really * much more simple than what boost::variant does internally. At least we are * pulling in fewer headers and the actual code path is shorter compared with - * boost::variant, at the price of beeing not so generic, not caring for + * boost::variant, at the price of being not so generic, not caring for * alignment issues within the buffer and being not threadsafe * * @param TYPES collection of possible types to be stored in this variant object @@ -234,8 +234,8 @@ namespace lumiera { typedef typename Holder::Deleter Deleter; - /** storage: buffer holding either and "empty" marker, - * or one of the configured pointer to wrapper types */ + /** storage: buffer holding either an "empty" marker, + * or an instance of one of the configured payload types */ typename Holder::Storage holder_; diff --git a/src/lib/wrapperptr.hpp b/src/lib/wrapperptr.hpp index c9b8bcd70..db168cba1 100644 --- a/src/lib/wrapperptr.hpp +++ b/src/lib/wrapperptr.hpp @@ -51,9 +51,9 @@ namespace lumiera { * with the possible hierarchy-base classes used within this application. * Thus, when passing in an arbitrary smart-ptr, the best fitting smart-ptr * type pointing to the corresponding base class is selected for internal storage. - * Later on, stored values can be retrieved either utilitzing static or dynamic casts; - * error reporting is similar to the bahaviour of dynamic_cast: when retrieving - * a pointer, in case of mismatch NULL is returned. + * Later on, stored values can be retrieved either utilising static or dynamic casts; + * error reporting is similar to the behaviour of dynamic_cast: when retrieving + * a pointer, NULL is returned in case of mismatch. */ typedef lumiera::Variant WrapperPtr; diff --git a/src/proc/mobject/placement-index.hpp b/src/proc/mobject/placement-index.hpp index 2df8be57e..86904591c 100644 --- a/src/proc/mobject/placement-index.hpp +++ b/src/proc/mobject/placement-index.hpp @@ -21,17 +21,17 @@ */ -/** @file placement-ref.hpp +/** @file placement-index.hpp ** - ** @see Placement - ** @see PlacementRef_test + ** @see PlacementRef + ** @see PlacementIndex_test ** */ -#ifndef MOBJECT_PLACEMENT__REF_H -#define MOBJECT_PLACEMENT__REF_H +#ifndef MOBJECT_PLACEMENT_INDEX_H +#define MOBJECT_PLACEMENT_INDEX_H //#include "pre.hpp" //#include "proc/mobject/session/locatingpin.hpp" @@ -48,7 +48,7 @@ namespace mobject { /** */ - class PlacementRef + class PlacementIndex { }; diff --git a/src/proc/mobject/placement-ref.hpp b/src/proc/mobject/placement-ref.hpp index 7e04514d7..a2035ea14 100644 --- a/src/proc/mobject/placement-ref.hpp +++ b/src/proc/mobject/placement-ref.hpp @@ -43,13 +43,21 @@ namespace mobject { // using std::tr1::shared_ptr; - + /** */ class PlacementRef { + /** + * + */ + class ID + { + }; + + }; diff --git a/tests/lib/factoryspecialtest.cpp b/tests/lib/factoryspecialtest.cpp index 6850f057a..26fda9084 100644 --- a/tests/lib/factoryspecialtest.cpp +++ b/tests/lib/factoryspecialtest.cpp @@ -188,8 +188,8 @@ namespace lumiera /******************************************************************* * testing the more advanced Factory variants and possibilities. - * We use several customized Factory subclasses supporting custom - * allocation, placement allocation, private construcors and + * We use several customised Factory subclasses supporting custom + * allocation, placement allocation, private constructors and * the PIpmpl design pattern. All creating smart pointers. */ class Factory_special_test : public Test diff --git a/wiki/renderengine.html b/wiki/renderengine.html index c99e9b671..0316aaf8d 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2800,15 +2800,34 @@ Placements have //value semantics,// i.e. we don't stress the identity of a plac -
+
An implementation facility used to keep track of individual Placements and their relations.
 Especially, the [[Session]] maintains such an index, allowing to use the (opaque) PlacementRef tags for referring to a specific "instance" of an MObject, //placed// in a unique way into the current session. And, moreover, this index allows for one placement referring to another placement, so to implement a //relative// placement mode. Because there is an index behind the scenes, it is possible to actually access such a referral in the reverse direction, which is necessary for implementing the desired placement behaviour (if an object instance used as anchor is moved, all objects placed relatively to it have to move accordingly, which necessiates finding those other objects).
 
+!questions {{red{WIP}}}
+What implementation approach to take for the index. This of course largely depends on the usage pattern, which in turn is not-yet existant. To start with, we need a preliminary implementation!
+
+Using a ''flat hashtable'' would allow to access a Placement denoted by ID in O(1). This way we could get the Placement, but nothing more. So, additionally we'd have to set up an data record holding additional information:
+* the scope containing this placement
+* especially the path "up" from this scope, which is used for resolving any queries
+* relations to other placements
+
+Alternatively, we could try to use a ''structure based index''. Following this idea, we could try to avoid the mntioned description record by folding any of the contained informations into the surrounding datastructure:
+* the scope would be obvious from the index, resp. from the path used to resolve this index
+* any other informations, especially the relations, would be folded into the placement
+* this way, the "index" could be reduced to being the session datastructure itself.
+
-
+
A generic reference mechanism for Placements, as added to the current session.
-While this reference itself is not tied to the actual memory layout (meaning it's //not// a disguised pointer), the implementation relies on a [[placement index facility|PlacementIndex]] for tracking and retrieving the actual Placement implementation object.
+While this reference itself is not tied to the actual memory layout (meaning it's //not// a disguised pointer), the implementation relies on a [[placement index facility|PlacementIndex]] for tracking and retrieving the actual Placement implementation object. + +!questions {{red{WIP}}} +Currently (5/09) ichthyo is in doubt what implementation to use best. It is clear that the PlacementRef needs to incorporate as the only actual data in memory, so it can be downcasted to a POD and passed as such via LayerSeparationInterfaces. And, of course, this ID tag should be the one used by PlacementIndex for organising the Placement index entries, thus enabling the PlacementRef to be passed immediately to the underlying index for resolution. Thus, the design decision boils down to the question how to implement the ID tag. +* a flat random hash, e.g. using a {{{LUID}}}? +* a structure based index, which also denotes the position in the (tree like) datastructure (Sequences within the session)? + 
//This page is a scrapbook for working out the implementation of how to (re)build the [[Fixture]]//