Hi all,
I don't really have any light to through on this problem with
osgIntrospection, but I'd like to flag up my willingness to look at
tweaking API in the OSG that causes problems like this. This will
have to be taken in a case by case, but perhaps introspection itself
can help flag the possible problem areas.
I'm looking into this. Conversions are perhaps the weakest point of
osgIntrospection and they are the main reason why I've decided to redesign
the library. Of couse it takes time to do that and I haven't had any yet.
:-/
As happens with many projects at their first design, osgIntrospection is the
result of an effort to implement too many things at the same level. I wanted
a library that could mimic the behaviour of the C++ language while still
being simple to use and to interface to languages that don't implement all
the features of C++ compilers. My planned future design will break the
current library into two abstraction layers: a lower layer that mirrors C++
features (pointers, references, conversions, name lookup, etc.) the same way
C++ defines them, and an higher layer that can optionally abstract away the
intricacies of C++ in favour of simplicity. One would then choose the former
or the latter layer depending on the required degree of freedom.
Back on topic. Quoting David:
when try to do a string convertion from string to a osgText::Font pointer,
the address give to the > pointer is a bad address If this address is use
... this is fatal ==>> SEGFAULT
Actually, if you try to convert a text string to any pointer type the
conversion will fail and Value::tryConvertTo() will return an empty Value,
which is the correct behaviour:
Value v;
if (dst_rw->readTextValue(ss, v))
{
return v;
}
the return statement is executed only if the read-from-stream operation
succeeds. If it fails, the function reaches its end and an empty Value is
returned.
[note to self: what happens if the string represents a valid number?
hmmmm.... ]
If you get a segfault, then the problem is somewhere else. A quick debugging
has almost convinced me that the bug is here:
[osgIntrospection/Value, from line 354]
template<typename T> Value::Value(const T *v)
{
_inbox = new Ptr_instance_box<const T *>(v);
_type = _inbox->type();
_ptype = _inbox->ptype(); // <<<------ BUG?
}
template<typename T> Value::Value(T *v)
{
_inbox = new Ptr_instance_box<T *>(v);
_type = _inbox->type();
_ptype = _inbox->ptype(); // <<<------ BUG?
}
the two lines I've marked with "BUG" are suspect because they don't check
whether the pointer v is null or not. If it's null, the call to
_inbox->ptype() will fail because it dereferences a null pointer. So, a fix
might be to replace the above lines with:
_ptype = v ? _inbox->ptype() : 0;
I'm a bit rusty on the code but this is my bet. It's too late now to
recompile and test the fix, I'll do that tomorrow. :-)
Cheers,
Marco
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
