Subject: [ggl] user controllable numeric conversion.
Date: 2010-05-04 06:19:55
>> 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.
What about use macro to switch between numeric_cast and implicit conversion?
# define NUMERIC_CAST(TargetType, Source) Source
# define NUMERIC_CAST(TargetType, Source)
then, in the code:
t = NUMERIC_CAST((target type here), (Source value here));
Using numeric_cast as default can make the complier output neat and
tidy. It should also work smoothly for common use.
User can define USE_IMPLICIT_CONVERSION when they don't want numeric_cast.
>> 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.
Well, from the doc, "transform" is for point-based transformation, while
"convert" is for conversion between different geometries. So I think it
is more suitable to put such numeric conversion in the transform part.
Geometry list run by mateusz at loskot.net