Variant type conversions (C++ API)...

[Toralf Lund <to...@pgs.com>]

Hi,

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?

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?

QPid version is 0.22.

- Toralf


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

Re: Variant type conversions (C++ API)...

[Gordon Sim <gs...@redhat.com>]

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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org