On 07/29/2015 11:50 AM, Toralf Lund wrote:
I have construct of the form

value=message.getProperties()["property"];

The expected property type is uint32. The value type has up until now
been "unsigned int", so (obviously) the call has worked just fine. But
then I changed it to a double (because I want to use it as a
floating-point later), and it will no longer work - get and "
InvalidConversion" exception with the message "Cannot convert from
uint32 to double (qpid/types/Variant.cpp:488)". This rather surprised
me; I can easily work around this, but why isn't an integer variant
convertible to a floating-point value?

I agree, there is no obvious reason why that should not work. If you want to raise a JIRA I can take a look at getting a fix in.

Also, when doing some more tests, I realised that I also get an
exception when the property is missing. This was also not quite what I
expected, either - based on experience with "variant" types in other
libraries, I assumed that an "empty" variant would be convertible to
most types - giving a 0 or default-constructed value. Comments?

This one for me is less clear. Treating null as 0 doesn't feel entirely right to me. At present you can convert a null (i.e. a void) into a string (the empty string) or a bool (false) but not into any of the numeric values. whether this is consistent and whether it should be changed is I suspect subject to different points of view. If there was a consensus on the list that a change of some form was needed I'd be happy to accept that of course.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to