Subject: [ggl] user controllable numeric conversion.
From: Barend Gehrels (barend.gehrels)
Date: 2010-04-29 17:37:18
Hi,
> I saw lots of numeric_cast spread around to perform numeric conversion
> between different coordinate type.
> numeric_cast is not so "general" for general programming (while the
> numeric::converter is). Although, user can still make their own coordinate
> type (UDT) to be available to numeric_cast, but the other traits of
> numeric::converter are fixed. And for built-in type conversion, it is
> totally out of user's control.
>
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.
> It is ok to put numeric_cast in interface for convenience. A more general
> way would add another interface with a numeric converter parameter. But that
> could be too troublesome for both user and developer.
> So my suggestion here would be
> 1. use numeric_cast in a limited range, be sure that would not bypass user's
> conversion.
>
what do you mean by a limited range? A range of the input coordinate type?
> 2. user should be notified not to mix using of different coordinate type
> that could be ill-formed(in the documentation).
> 3. If user wants to use their own numeric converter, they should explicitly
> use the transform algorithm.
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
> To make it simple, make
> transform_strategy::apply() accepts another numeric converter parameter, and
> also add two interfaces of transform algorithm to accept converter parameter
> which would be passed to transform_strategy::apply(). The two original
> transform interfaces can be applied with numeric_cast as default converter.
> If it would result problem in current code, at least make another
> copy_per_coordinate like strategy that can be explicitly constructed from a
> numeric converter which would be used in apply(). Such strategy would be
> dedicated for coordinate type conversion, but is less convenient than the
> previous approach.
>
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?
Regards, Barend