Ticket #57 (closed defect: fixed)
Class naming changes proposal
|Reported by:||mloskot||Owned by:||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] <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,