planning index structure..

src/lib/accesscasted.hpp

@@ -27,10 +27,10 @@
  ** and the target type (type we need within the usage context). 
  ** When instantiating AcessCasted<TAR>, we get a template static function
  ** \c AcessCasted<TAR>::access<SRC>(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<TAR>::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

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 <b>not threadsafe</b>. 
+ ** doesn't deal with alignment issues and is <b>not threadsafe</b>. 
  ** 
  ** 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 <b>not threadsafe</b>
    * 
    * @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_;
       
       

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<T>: 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<T>: when retrieving
+   * a pointer, NULL is returned in case of mismatch.
    */
   typedef lumiera::Variant<WrapperTypes, util::AccessCasted> WrapperPtr;
   

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
     {
     };
   

src/proc/mobject/placement-ref.hpp

@@ -43,13 +43,21 @@
 namespace mobject {
 
 //  using std::tr1::shared_ptr;
-
+  
   
   
   /**
    */
   class PlacementRef
     {
+      /**
+       * 
+       */
+      class ID
+        {
+        };
+      
+      
     };
   
   

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

wiki/renderengine.html

@@ -2800,15 +2800,34 @@ Placements have //value semantics,// i.e. we don't stress the identity of a plac
 
 </pre>
 </div>
-<div title="PlacementIndex" modifier="Ichthyostega" created="200905090053" tags="SessionLogic spec impl draft" changecount="1">
+<div title="PlacementIndex" modifier="Ichthyostega" modified="200905091529" created="200905090053" tags="SessionLogic spec impl draft" changecount="3">
 <pre>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 &quot;instance&quot; 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 &quot;up&quot; 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 &quot;index&quot; could be reduced to being the session datastructure itself.
+
 </pre>
 </div>
-<div title="PlacementRef" modifier="Ichthyostega" created="200905090032" tags="def spec draft" changecount="1">
+<div title="PlacementRef" modifier="Ichthyostega" modified="200905091516" created="200905090032" tags="def spec draft" changecount="2">
 <pre>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.</pre>
+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)?
+</pre>
 </div>
 <div title="PlanningBuildFixture" modifier="Ichthyostega" modified="200801061937" created="200712100445" tags="impl Builder draft" changecount="11">
 <pre>//This page is a scrapbook for working out the implementation of how to (re)build the [[Fixture]]//