[osg-users] Meta-data in core OSG - project started

D.J. Caldwell dlcaldwelljr at gmail.com
Fri Apr 29 20:20:13 PDT 2011


Hi, all...

I just realized, if you write your proxy correctly, your original class
Value<T> probably works just fine for more exotic types (when T is your
proxy class giving access to the underlying type), without my proposed
interface layer.  In fact, for purposes of reference semantics, the original
is probably preferred.

Perhaps I should have read that doc more than three times...

Regardless, I look forward to your comments and the final product.

D.J.

On Fri, Apr 29, 2011 at 11:01 PM, D.J. Caldwell <dlcaldwelljr at gmail.com>wrote:

> Hi Sukender and fellow interested parties,
>
> I've finally had a chance to review your meta-data doc (version 4) to see
> what you all have been designing, and how we might be able to use it in our
> project.
>
> Overall, I must say the design looks good.  I really appreciate the effort
> you have put into it.
>
> I do have a few design points you may (not) find interesting, so feel free
> to accept/modify/comment/ignore as you see fit (as long as you take credit
> for any mods/comments that you make ;-) ).  If you think I've misunderstood
> something, feel free to give me pointers where I may have gone off track; I
> only hope I am not stating the obvious, thereby wasting people's time.
>
> 1) By deprecating user data and description lists, and integrating them
> into the proposed meta-data system until those interfaces are removed, you
> have some major side effects:
>     a) With the current proposal, replacing a meta-data container destroys
> any legacy user data or descriptions that may already be present.  If this
> is a desirable side effect, so be it, but users should be explicitly made
> aware of this side effect.
>     b) User data and description lists will not be a viable work around
> (because they will are deprecated) for users who cannot, or will not,
> convert to the new meta-data system and also do not wish to replace any
> existing meta-data on a node.  They will be forced to use some other means
> (probably external) to store their data.  Again, if this is a desirable side
> effect, so be it.
>     c) For data base accessors, user data and/or description lists may
> (not) be totally inappropriate when choosing the "proxy container" route; a
> meta-data value that holds a "proxy container" may be preferred.  I have
> little to know experience with data bases, so others will have more insight
> into this sort of thing, but I thought it worth mentioning.
>
> 2) I think you might be missing an interface layer that is necessary for
> the type system to work for user defined containers that have "proxy"
> values, but do not want to pay the default cost of storing a T value:
>
> [code]
>
> // slight mod from current design
> class ValueBase : public Referenced
> {
> protected:
>     // do we not need a virtual destructor here, since containers will
>     // hold ref_ptr to this?
>     virtual ~ValueBase() {}
> };
>
> // type specific interface for getting type specific values into/out of
> // containers, without revealing how the value itself is stored here
> template<typename T> ValueT : public ValueBase
> {
> public:
>     // interface layer needs to able to virtually assign values; copy
>     // constructors need more detail, so we must go to the most derived
>     // type for that, and we should be using clone for that anyway
>     ValueT& operator=(const ValueT& val)
>     { xassign(val.value()); return *this; }
>     ValueT& operator=(const T& val) { xassign(val); return *this; }
>     virtual T & value() = 0;
>     virtual const T & value() const = 0;
>     // const so we can use it anywhere excpet for assignment to this
>     // value
>     operator T() const { return value (); }
> protected:
>     // derived types tend to need explicitly defined destructors
>     virtual ~ValueT() {}
> private:
>     // yes, this is virtual and private, but client code should not be
>     // calling this unless we provided "set" methods other than straight
>     // assignment; the pattern is unusual, but it works
>     virtual void xassign(const T& val) = 0;
> };
>
> // renamed from "Value<T>" with slight mods
> template<class T> class BasicValue : public ValueT<T>
> {
> public:
>     //virtual const char * className() const;
>     /** Constructor*/
>     BasicValue() {}
>     /** Contructor from T.*/
>     BasicValue(const T& val) { _value = val; }
>     /** Copy constructor*/
>     BasicValue(const BasicValue<T>& val) { _value = val._value; }
>      BasicValue& operator=(const T& val) { _value = val; return *this; }
>     BasicValue& operator=(const BasicValue& val) { _value = val._value;
> return *this; }
>     T & value() { return _value; }
>     const T & value() const { return _value; }
>     /* Implicit conversion */
>     // see ValueT, above
>     //operator T() { return _value; }
> protected:
>     /** the stored value*/
>     T _value;
>     // derived types tend to need explicitly defined destructors
>     virtual ~BasicValue() {}
>     /** overloaded == operators, we have to be extra careful because T type
> doesn't necessarily have ==
>     * overloaded.*/
>     friend inline bool operator==(const BasicValue<T>& left,const
> BasicValue<T>& right){ return left._value==right._value; }
>     friend inline bool operator==(const T& left,const BasicValue<T>&
> right){ return left==right._value; }
>     friend inline bool operator==(const BasicValue<T>& left,const T&
> right){ return left._value==right; }
> private:
>     // virtual assignment for use with the interface layer, ValueT<T>
>     virtual void xassign(const T& val) { _value = T; }
> };
>
> [/code]
>
> By "forcing" users to derive from the interface template, ValueT<T>, you
> can guarantee a common type safe interface for casting inside your generic
> meta-data containers, without the expense of storing T objects locally.
> Your existing class, Value<T> (I renamed it BasicValue<T>) will still work
> for initialization with plain old data types and compatible types, but you
> do not have to pay for the storage of a potentially useless T object for
> more exotic types (data base accessors, etc).
>
> Thanks, again, and I look forward to seeing the final product.
>
> D.J.
>
> On Thu, Apr 28, 2011 at 3:26 AM, Torben Dannhauer <torben at dannhauer.info>wrote:
>
>> Hi all,
>>
>> this meta system looks very interesting. I started to implement such a
>> system for osgVisual for data management, but it seems that your approach is
>> much more sophisticated and finally allows me to plug in my use cases quite
>> easy.
>> I'm happy that such a framework is developed for OSG. I have cross-read
>> the V4 document, but unfortunately I'm currently too much occupied by my
>> doctoral thesis to add usefull ideas/components. I'll try to stay up to date
>> and maybe can add some comments.
>>
>> Thanks for your effort, it is great work!
>>
>> Best regards from Salzburg,
>> Torben
>>
>> ------------------
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=38841#38841
>>
>>
>>
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20110429/12c08937/attachment-0004.htm>


More information about the osg-users mailing list