id summary reporter owner description type status priority milestone component version severity resolution keywords cc 57 Class naming changes proposal mloskot strk "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] nhv: have you any idea how to force vc++ to not to see his own dump max/min macros? [19:48] std::max(env->getHeight(), env->getWidth()); [19:48] and to std::max vc++ tries to put max macro ;-)) [19:49] So, I get there: error C2589: '(' : illegal token on right [19:49] -DNOMINMAX [19:49] thanks, checking [19:57] yup, it works [19:58] * nhv knew it would [19:58] as this is a well known problem with hence the MACRO [20:00] *** eighty (n=eighty@bot-1751a-1751a-003-d.Garden.Berkeley.EDU) joined [20:01] yup [20:01] I usually used #undef [20:02] Hehe, another strange problem [20:02] http://rafb.net/paste/results/vSQbHR63.html [20:03] There is no window related header included in GEOS, so why VC++ tries to use it? [20:03] Hmm. [20:03] strk won't be happy to use fully qualified name for Polygon or Point :-))) [20:08] nhv: do you have any magical solution? [20:11] we should probably change the GEOS names thank you Microsoft [20:11] Hehe,but you know. In normal situation, you don't have to because they're in its own namespace geos::geom:: [20:12] The problem is that in .cpp files we use using namespace geos::geom; [20:12] but even then VC++ should not see any GDI stuff, because no GDI header is included. [20:12] Wrrr, I have such problems :-) [20:13] one idea is to use geos::geom::Polygon in every place [20:13] try using -DWIN32_LEAN_AND_MEAN -DNOGDI [20:14] this might actually compile fastr too [20:14] checking [20:18] http://groups.google.pl/group/microsoft.public.vc.atl/browse_frm/thread/a162825db1707688/ [20:18] but it's quite old post, from 1999 [20:18] It seems that using NOGDI helps. [20:18] I have geos compiled :-) [20:18] nhv: Thanks [20:19] right that precludes Polygon and Point [20:20] LEAN_AND_MEAN leaves out lots of Windows specific headers [20:20] yse, I know that leanandmean [20:20] but users might have problems if these are exposed in a header that a GEOS user would include [20:20] I didn't know NOGDI [20:20] * nhv never uses MSVC either :-) [20:20] Right, there may be a problem when using GEOS on Windows with GDI stuff. [20:21] then fully qualified names should be used. [20:21] *** eighty quit ( ) [20:21] except I think these are #defines in MSOFT [20:21] I wish to not to have to write software for Windows :-) [20:22] But you know, I'm on the start of my way to do what I want and like ;) [20:23] I think we should use GEOSPoint and GEOSPolygon [20:23] as these are likely to cause problems with other systems too [20:23] you're right, but such problems should be solved by namespaces. [20:23] ote this is a common practice eg OGRPolygon etc [20:24] another story is Windows API does not use namespaces [20:24] 'C' doesn't have namespaces [20:24] yup, }}}" defect closed major Core svn-trunk Content fixed imported,phpbugtracker