[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
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?
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,
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?
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:
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
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 :-) ).
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,
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 :-) ).
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. It has to be (x,y).
Your first sample listed:
{0, 0}, {1, 0}, {1, 1}, {0, 1}, {0, 0} So this is lower-left, lower-right, upper-right, upper-left, lower-left. So counter-clockwise.
There is a function to correct it (boost::geometry::correct) so no problem.
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<<.
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).
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>>>'
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
Your first sample listed:
{0, 0}, {1, 0}, {1, 1}, {0, 1}, {0, 0} So this is lower-left, lower-right, upper-right, upper-left, lower-left. So counter-clockwise.
Oh, I get it now. I was thinking in terms of screen coordinates, where (0, 1) is below (0, 0). I see now that it's intended to be like a standard coordinate plane, where (0, 1) is above (0, 0). Right?
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.
Is this in SVN anywhere? I only have the formal_review sources. - Kef
Hi Kef,
So this is lower-left, lower-right, upper-right, upper-left, lower-left. So counter-clockwise.
Oh, I get it now. I was thinking in terms of screen coordinates, where (0, 1) is below (0, 0). I see now that it's intended to be like a standard coordinate plane, where (0, 1) is above (0, 0). Right? I see, good point. Yes, that is the intention. In a future version both will be supported.
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.
Is this in SVN anywhere? I only have the formal_review sources. Yes, but still at my company. It will be moved soon. I can make an account for you though.
Barend
participants (2)
-
Barend Gehrels -
Kef Schecter