Re: [boost] [Polygon] "Ambiguous use of partial specialization" in CodeWarrior

Subject: Re: [boost] [Polygon] "Ambiguous use of partial specialization" in CodeWarrior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-01-10 23:51:53

Thomas Klimpel wrote:
> Kef Schecter wrote:
>> It doesn't help, I'm afraid. I get exactly the same errors -- no
>> more, no less.
> 
> I'll take another shoot at this. I patched polygon_traits.hpp a
> little to require less SFINAE "power" from the compiler. 
> 
> So can you try the attached patch to polygon_traits.hpp, and add the
> line #define BOOST_VERY_LITTLE_SFINAE
> before the line that contains the include statement for polygon.hpp?

Wow, thanks!  I'll take a look at your patch tomorrow and check in the changes.  I have a new one week old at home, bringing the total to five children, and didn't get to Kef's problem yet except to verify what the issue was.
 
> As a side note, the latest revision of Boost.Polygon doesn't pass all
> regression tests on MSVC-9.0 (basically the "std::map" from "typedef
> std::map<half_edge, property_map, less_half_edge> scanline_type;"
> complains at runtime that "less_half_edge" implements an "invalid
> operator<"). The last revision that works for me is r58551, the first
> revisions that fails for me is r58795.     

The last three weeks I've been putting a lot of work into optimizing the general angle algorithms to minimize the use of infinite precision while maintaining robustness.  The change to the less than operator is supposed to make comparisions of segments in the tree depend upon only my robust slope comparison predicate and not infinite precision calculations of precise coordinate values.  I imagine there is some sort of runtime assertion baked into the MSVC stl that I'm failing.  This is a bit surprising since the library is working quite well in my testing.  I guess I'll have to update the code in my windows dev environment and chase this issue down.

On the plus side, I've eliminated all use of infinite precision numerical data types for predicates and all but the case where long double fails for constructions.  This means that the library is equally as fast with as without gmp robustness since long double fails only rarely with coordinates in the integer range.  

Thanks again,
Luke