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

Subject: [ggl] user controllable numeric conversion.
From: feverzsj
Date: 2010-05-04 06:19:55

hi,

>>    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?

for example:

#ifdef USE_IMPLICIT_CONVERSION
#    define NUMERIC_CAST(TargetType, Source) Source
#else
#    define NUMERIC_CAST(TargetType, Source) 
::boost::numeric_cast<TargetType>(Source)
#endif

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.

Regards, ZhouShuangJiang