Geometry Boost List: [ggl] Surprising ADL

Subject: [ggl] Surprising ADL
From: feverzsj
Date: 2010-05-05 11:07:27

hi Barend,
>>
>>    The following code won't compile on msvc8/9, and both of the 
>> compliers give the same diagnostic output for "ambiguous call to 
>> overloaded function" and "one of the overloads is found by ADL".
>
> This is indeed unexpected.
>
>
>>
>> I think that's mainly because of the unqualified call inside 
>> boost::geometry::transform().
>
> That will probably be the case and if so, solved easily (though this 
> construction is of course everywhere).
>
> We can solve it when adding namespaces (algorithm, model) everywhere, 
> as was planned some months ago. Do you need it be solved immediately?
That will be so grateful, since there are some similar cases in my project.

Talking of ADL, I also found some part of the lib use qualified call to 
stdlib functions, which will forbid the use of ADL.
For example, in 
boost::geometry::detail::overlay::enrich_containment::enrich(), the 
qualified std::abs() will forbid the user from using his own abs() for UDT.

Furthermore, I am not so clear about what kind of UDT can be used as 
coordinate type. From my point of view, it seems the lib suppose the 
standard arithmetic operations are supported for all the built-in 
type(especially, floating point types). And the UDT is based on such 
assumption. For example, if user uses some fixed point type as 
coordinate type, and expects the lib to act upon the fixed point 
arithmetic(coming with the fixed point type), he will not get what he 
wants(e.g., distance algorithm won't compile, since there is no proper 
result type).

Regards, ZhouShuangJiang