On Windows, GEOS names may be in conflict with some names (macros, functions, structs) visible globally, because of lack of namespaces in C (Windows API is a C API).
Example of error:
__projectsgeos_cvs_refactoredgeossourceoperationpredicaterectanglecontains.cpp(49) : error C2872: 'Polygon' : ambiguous symbol
could be 'c:program filesmicrosoft visual studio 8vcplatformsdkincludewingdi.h(4002) : BOOL Polygon(HDC,const POINT *,int)'
or
'd:__projectsgeos_cvs_refactoredgeossourceheadersgeosgeompolygon.h(55) : geos::geom::Polygon'
I've talked about this issue with Norman Vine on #postgis and here is his proposal with that I agree:
[19:48] <mloskot> nhv: have you any idea how to force vc++ to not to see his own dump max/min macros?
[19:48] <mloskot> std::max(env->getHeight(), env->getWidth());
[19:48] <mloskot> and to std::max vc++ tries to put max macro ;-))
[19:49] <mloskot> So, I get there: error C2589: '(' : illegal token on right
[19:49] <nhv> -DNOMINMAX
[19:49] <mloskot> thanks, checking
[19:57] <mloskot> yup, it works
[19:58] * nhv knew it would
[19:58] <nhv> as this is a well known problem with <windows.h> hence the MACRO
[20:00] *** eighty (n=eighty@bot-1751a-1751a-003-d.Garden.Berkeley.EDU) joined
[20:01] <mloskot> yup
[20:01] <mloskot> I usually used #undef
[20:02] <mloskot> Hehe, another strange problem
[20:02] <mloskot> http://rafb.net/paste/results/vSQbHR63.html
[20:03] <mloskot> There is no window related header included in GEOS, so why VC++ tries to use it?
[20:03] <mloskot> Hmm.
[20:03] <mloskot> strk won't be happy to use fully qualified name for Polygon or Point :-)))
[20:08] <mloskot> nhv: do you have any magical solution?
[20:11] <nhv> we should probably change the GEOS names thank you Microsoft
[20:11] <mloskot> Hehe,but you know. In normal situation, you don't have to because they're in its own namespace geos::geom::
[20:12] <mloskot> The problem is that in .cpp files we use using namespace geos::geom;
[20:12] <mloskot> but even then VC++ should not see any GDI stuff, because no GDI header is included.
[20:12] <mloskot> Wrrr, I have such problems :-)
[20:13] <mloskot> one idea is to use geos::geom::Polygon in every place
[20:13] <nhv> try using -DWIN32_LEAN_AND_MEAN -DNOGDI
[20:14] <nhv> this might actually compile fastr too
[20:14] <mloskot> checking
[20:18] <mloskot> http://groups.google.pl/group/microsoft.public.vc.atl/browse_frm/thread/a162825db1707688/
[20:18] <mloskot> but it's quite old post, from 1999
[20:18] <mloskot> It seems that using NOGDI helps.
[20:18] <mloskot> I have geos compiled :-)
[20:18] <mloskot> nhv: Thanks
[20:19] <nhv> right that precludes Polygon and Point
[20:20] <nhv> LEAN_AND_MEAN leaves out lots of Windows specific headers
[20:20] <mloskot> yse, I know that leanandmean
[20:20] <nhv> but users might have problems if these are exposed in a header that a GEOS user would include
[20:20] <mloskot> I didn't know NOGDI
[20:20] * nhv never uses MSVC either :-)
[20:20] <mloskot> Right, there may be a problem when using GEOS on Windows with GDI stuff.
[20:21] <mloskot> then fully qualified names should be used.
[20:21] *** eighty quit ( )
[20:21] <nhv> except I think these are #defines in MSOFT
[20:21] <mloskot> I wish to not to have to write software for Windows :-)
[20:22] <mloskot> But you know, I'm on the start of my way to do what I want and like ;)
[20:23] <nhv> I think we should use GEOSPoint and GEOSPolygon
[20:23] <nhv> as these are likely to cause problems with other systems too
[20:23] <mloskot> you're right, but such problems should be solved by namespaces.
[20:23] <nhv> ote this is a common practice eg OGRPolygon etc
[20:24] <mloskot> another story is Windows API does not use namespaces
[20:24] <nhv> 'C' doesn't have namespaces
[20:24] <mloskot> yup,
