Hi David,
I don't see anything to avoid convertion from string to pointer.
reading a pointer from a stream fails if the stream doesn't contain a valid
decimal or hexadecimal number (which can be converted to a pointer address).
This is the behaviour of the STL.
the std::istream& ReaderWriter::readTextValue(std::istream &, Value& v,
const Options* = 0)
function return a reference and so always return true.
The standard stream classes (like istream) have an operator bool() that make
them evaluate to true or false depending on the stream state (true if the
stream is in good state, false otherwise). The readTextValue() function
attempts a conversion by reading the target value from the stream. If the
conversion fails, for example because you are trying to read a number or
pointer value from a non-numeric string, the stream goes into "fail" state
and the returned reference to istream will evaluate to false. This is again
a common pattern used throughout the STL.
and here, static_cast<Instance<T> *>(inst_)->_data is not null and is
equal to "0xf"
this cause the call of typeof(*static_cast<Instance<T> *>(inst_)->_data)
and the typeid of the deferenced pointer cause the SEGFAULT.
Well, this is what I wrote in my previous email. The point is, the behaviour
of tryConvertTo is correct. The bug is somewhere else.. :-)
The test that you want to do
_ptype = v ? _inbox->ptype() : 0;
is already done in :
virtual const Type* ptype() const
{
if (!static_cast<Instance<T> *>(inst_)->_data) return 0;
return &typeof(*static_cast<Instance<T> *>(inst_)->_data);
}
"inst_->_data" is equal to "v" after inst_ initialisation.
That's correct. And now I'm really puzzled. According to my debugger, the
exception is being raised because the second line of ptype() tries to get
the type of a dereferenced null pointer. But if the pointer is null, how can
it pass the test in the first line? Perhaps the debugger is wrong, I mean
the pointer is not null but it points to garbage data, or maybe this is just
the result of some memory corruption... This is even worse.
Marco
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
