[GGL] Can't seem to use equals on multi_polygons

When I try to use equals() on multi_polygons, the compiler blows up, giving a template error. I've tried this in CodeWarrior and MSVC. Using equals() on two polygon_2d's works fine, but it doesn't like it when I use multi_polygons. Is equals() for multi_polygons not implemented, or am I just missing something? I've attached a test program that demonstrates the problem. (I've defined my own integer-based types, like polygon_2di, because I need this to work on an embedded platform with no FPU. Using polygon_2d and doubles instead shows the same problem, though.) - Kef

Sorry, where are my manners? The file I had attached had much more than was necessary to demonstrate the problem. Here, this is a trivial one: #include <iostream> #include <ggl/ggl.hpp> #include <ggl/geometries/cartesian2d.hpp> #include <ggl/multi/geometries/multi_polygon.hpp> int main() { ggl::multi_polygon<ggl::polygon_2d> mp1, mp2; std::cout << "mp1 equals mp2?" << (ggl::equals(mp1, mp2) ? "YES" : "NO") << std::endl; return 0; }

Hi Kef,
You are right, equals for multi* is not yet there. I planned to put a new version there this weekend, anyway, so will take care that it is included. Intersections are enhanced in that new version. However, they should still be oriented clockwise in this version (the definitions from your first samples are counter-clockwise (so it was useful them being there :-) ). Is GGL running fine using CodeWarrior? By the way, GGL is renamed to Boost.Geometry, so you will have to rename ggl:: to boost::geometry or create an alias. Regards, Barend

Wait... my coordinates were counter-clockwise? I'm confused... are they supposed to be specified in (y, x) order instead of (x, y)? I assumed they were (x, y), in which case the coordinates would be clockwise: right, down, left, up.
Is GGL running fine using CodeWarrior?
For the most part, yes. There were a couple of hacks I had to make: * I had to change cartesian_distance::operator<< to use a plain ol' ostream instead of a basic_ostream<Char, Traits>. CodeWarrior didn't like the use of a template there, apparently. Using a plain ostream is fine for the purposes of my program -- in fact, the final program will use no streams at all. (Somebody on IRC suggested an alternative solution that might allow for the template, but I haven't tried it yet.) * I applied the same hack to dsv_manipulator::operator<<. There is also another problem I've just discovered: * get_not_intersecting_holes<polygon_tag>::apply (from ggl/algorithms/overlay/assemble.hpp) does not compile correctly. I thought maybe the code I'm using doesn't need it anyway, but I tested it and it seems I thought wrong. This is the part it chokes on: typename boost::range_const_iterator < typename interior_type<Polygon>::type >::type rit = boost::begin(interior_rings(polygon)); std::vector<bool>::const_iterator iit = boost::begin(intersecting); This yields this error message: Error : illegal implicit conversion from 'std::__bit_iterator<Metrowerks::__bitvec_deleter<std::allocator<bool>>, false>' to 'std::__convert_iterator<std::__implicit_convert<const bool *, std::__bit_iterator<Metrowerks::__bitvec_deleter<std::allocator<bool>>, true>>>' - Kef

Hi Kef,
Your first sample listed:
There is a function to correct it (boost::geometry::correct) so no problem.
OK, thanks. AFAIK this was a normal and correct usage of templates there. So we can probably use defines there, for CW. Or that IRC suggestion (which I don't have).
So it seems not to like the std::vector<bool>. I just checked assemble.hpp, it has been revised. The std::vector<bool> is removed already. If you are using union's, you are indeed using assemble, behind the screens. Regards, Barend
participants (2)
-
Barend Gehrels
-
Kef Schecter