Hi Sergey,
Thank you for the links.
You're right when saying variant causes a lot of issues. I won't bring an
answer about Variant here, but just some points about the current design:
I must say I wondered about adding a support for basic types (conversion
from/to int/string/double...). The question is: which types should be
considered as basic? fundamental types only? string? vector<string>?... Well it
depends on the usage actually. And the problem with a variant, as described in
trac.rtmpd.com, or the one in boost.variant, is that you must know (into OSG)
all the types you'll use beforehand. Which is pretty impossible regarding to
the different uses.
This is why I preferred something very neutral (hence osg::ValueBase). Of
course another problem arises: it's very common to need the type of a ValueBase
to get its (casted) value, or trigger specific code, etc (as specified in
section 3 of the PDF you sent the link). For now, and using current
implementation draft, we wrote a simple (yet very slow) solution with
dynamic_cast:
unsigned int getType(...) {
if (dynamic_cast<osg::Value<TYPE_1>*>(p)) return ...;
if (dynamic_cast<osg::Value<TYPE_2>*>(p)) return ...;
// etc.
}
This is clearly too slow if you call the function too ofen. Fortunately for us
this seems not critical at all. And this is less memory consuming creating a
"TypedValueBase" class, storing an integer (for instance) indicating the type.
But this may be useful to some developpers which often ask for the type of a
value. The base class would then look like:
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;
ValueType getType() const { return _type; }
protected:
ValueType _type;
};
or
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType; // Should this be a string?
virtual ValueType getType() const =0;
};
or you may imagine the same virtual methods as Node (className(),
libraryName(), etc...)
Then using this base class you could create, say, TypedValueInt,
TypedValuePotato, etc.
Do you think this should be provided in core OSG alongside (and as an
alternative to) Value<T>? Which version of TypedValueBase do you prefer?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "Sergey Kurdakov" <sergey.fo...@gmail.com> a écrit :
> Hi Sukender,
>
> concerning Variant,
> for simple types
>
> something like
> http://trac.rtmpd.com/browser/trunk/sources/common/src/utils/misc/variant.cpp
> http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variant.h
> http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variantmap.h
>
> might go,
>
> but it looks like you would like more, then discussion here
> http://stackoverflow.com/questions/5319216/implementing-a-variant-class
> ( esp use of boost variant instead of boost any ) might be of some
> use.
>
> My concern though is about speed of dynamic cast ( which is slow ), so
> maybe sort of custom rtti ( see example
> http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C4231214774C16E32EA2B2C879DAACB3?doi=10.1.1.164.1009&rep=rep1&type=pdf
> ) could be used here...
>
> but if custom rtti
> here comes to mind http://www.rcs.hu/Articles/RTTI_Part1.htm
> http://www.rcs.hu/Articles/RTTI_Part2.htm and then both osgReflection
> (now osgIntrospection ) and Wang Rui's reflection wrappers should be
> considered as they already have some functionality.
>
> so simple question of variant ( and degree of it's complexity and it's
> speed and then maybe serialization of very special variant ) causes a
> lot of issues to surface.
>
>
> Regards
> Sergey
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
