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

Subject: [ggl] user controllable numeric conversion.
From: feverzsj
Date: 2010-05-02 02:53:28

hi,

Barend Gehrels wrote:
> 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. AFAIK, numeric_cast is expected 
to use with built-in type. UDT cannot benefit from the boost numeric 
conversion framework via numeric_cast. 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)
    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.

>   what do you mean by a limited range? A range of the input coordinate 
> type?

Almost...
But, I think implicit conversion would be more suitable and simple.
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.

> But what about other algorithms? In many cases you can mix coordinate 
> types (e.g. distance). Until now I didn't care about the handlers and 
> accepted the default handlers. It is indeed (too?) complex to 
> implement such a facility everywhere
It seems more about something like promotion_traits, while numeric_cast, 
here, has less(or nothing) to deal with.

> It is then only valid for transform, and yes that might make sense. 
> The use has to copy but can at least do exactly what (s)he wants.
>
> Anyway, I think the current implementation can already do a thing like 
> this. Because a user can specify:
>
> // user defined function
> template <typename P1, typename P2, typename Converter>
> struct my_convert_transformer
> {
>    inline bool apply(P1 const& p1, P2& p2) const
>    {
>        boost::geometry::set<0>(p2, 
> Converter::convert(boost::geometry::get<0>(p1)));
>        boost::geometry::set<1>(p2, 
> Converter::convert(boost::geometry::get<1>(p1)));
>        return true;
>    }
> };
>
>
> which calls the static method convert of the specified extra template 
> parameter, which can be any converter including specific handlers.
>
> Indeed the "copy_coordinates" function could be extended to avoid 
> specifying dimensions explicitly like above. That could be done by 
> user code as well but we might provided this, like the 
> my_convert_transformer could also actually be provided by default as 
> well, indeed. Good point.
>
> The difference with your proposal is that it is here a template 
> parameter, not passed (so can only accept static methods).
>
> Do you think this is sufficient?
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.

Regards, ZhouShuangJiang