Ticket #57 (closed defect: fixed)

Opened 8 years ago

Last modified 6 years ago

Class naming changes proposal

Reported by: mloskot Owned by: strk
Priority: major Milestone:
Component: Core Version: svn-trunk
Severity: Content Keywords: imported,phpbugtracker
Cc:

Description

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,

Change History

Changed 8 years ago by strk@…

  • resolution changed from none to not a bug
Namespace qualification should fix this, right ?
I'll close this item, feel free to send patches
with qualifications when appropriate.

Changed 7 years ago by mloskot

  • status changed from closed to reopened
  • reporter changed from mateusz@… to mloskot
  • resolution not a bug deleted
  • version changed from 3.0.0 to svn-trunk
  • milestone imported deleted

Changed 7 years ago by mloskot

  • status changed from reopened to closed
  • resolution set to fixed
  • milestone set to 3.0.0

Changed 7 years ago by mloskot

  • status changed from closed to reopened
  • resolution fixed deleted

Changed 7 years ago by mloskot

  • owner changed from to strk
  • status changed from reopened to new

Changed 7 years ago by mloskot

  • status changed from new to closed
  • resolution set to fixed

Changed 7 years ago by mloskot

  • priority changed from 3 to major
  • severity changed from Annoyance to Content

Changed 6 years ago by anonymous

  • milestone 3.0.0 deleted

Milestone 3.0.0 deleted

Note: See TracTickets for help on using tickets.