Geometry Boost List: [ggl] user controllable numeric conversion.

Subject: [ggl] user controllable numeric conversion.
From: Barend Gehrels (barend.gehrels)
Date: 2010-05-04 03:49:33

Hi,

>> I see. I had to recapitalize this for myself, so numeric_cast is a 
>> convenience function for numeric::converter and with the latter you 
>> have several handlers to control overflow, rounding etc. With the 
>> numeric_cast they are filled out by default and so indeed out of 
>> control. 
>
>    For built-in type, numeric_cast supplies better runtime range 
> check, but conversion related compiler warnings are bypassed. For any 
> UDT(user defined type) related conversion, numeric_cast is same as 
> static_cast, and UDT must supply its own conversions. 
Sure but I don't think that is a problem, on the contrary, you have all 
the influence yourself by specialization.

> AFAIK, numeric_cast is expected to use with built-in type. UDT cannot 
> benefit from the boost numeric conversion framework via numeric_cast. 

I tried and it is certainly possible. numeric_cast is just a convenience 
function calling numeric::converter

> Thus, numeric_cast is not suggested to use in general code. (There is 
> a related mail here: 
> http://lists.boost.org/boost-users/2006/03/17847.php)
That mail is very interesting thanks for the link.

>    Although numeric_cast does improve the conversion between build-in 
> type(mostly for runtime range checking), I think it is better to use 
> implicit conversion(simply do nothing). With implicit conversion, user 
> can get well-informed about numeric type conversion related warning(, 
> while compiling). Implicit conversion of c++ is also carefully 
> designed to cope with general programming(some help are still needed, 
> e.g. promotion_traits). Since most users are more familiar with the 
> C++'s standard conversion, they will naturally choose a user defined 
> conversion for their own type. As for runtime range checking, not all 
> users want them. Some users expect the general code they using to be 
> as plain as it is.

That is a good point. Removing numeric cast is simple of course, but 
will change functionality, warnings and checks. I'm a bit hesitating to 
do that.

>
>
> Furthermore, I found some input function is not coincident with others 
> for use of numeric_cast;
> For example, set() requires the input value to be the same as 
> geometry's coordinate type, while assign() will accept any possible 
> type can be converted by numeric_cast and use numeric_cast internally.
Yes, that is true. It is a choice. With assign you can even use strings 
to assign points, useful for high precision.
I don't remember why it is not done like that in set.

>>
> As of now, after reviewing my proposal in a whole sense, I think it is 
> reasonable to keep algorithms to do the standard like 
> conversion(static_cast/implicit conversion) and use another transform 
> strategy to make special numeric conversion. Yes, something like 
> my_convert_transformer would be sufficient.

We have also the "convert" algorithm, going from e.g. ring to polygon, 
or vice versa (loosing internal rings), which is also suitable to 
convert numeric types.

Thanks for all your input.

Regards, Barend