[Fwd: [Boost-users] [boost] Formal Review: Boost.Polygon
starts today August 24, 2009]
Barend.Gehrels at geodan.nl
Tue Sep 1 19:21:53 EDT 2009
Hartmut Kaiser wrote:
>> Martin Davis wrote:
>>> Hmmm... GEOS comes off rather badly compared to GGL. Is that because
>>> of memory access issues? Or perhaps the fact that less code is
>> It's hard to judge, but I'm quite sure inlining is only a small and
>> minor optimisation available.
>> GEOS and GGL follow completely different programming paradigms.
>> GGL is strongly based on static polymorphism resolved and calculated in
>> compile-time. This increases changes that compilers will apply finest
>> possible optimisations.
> >From what I've seen in GEOS and GGL, GEOS is mostly relying on dynamic
> memory allocation, where GGL tries to avoid that. GEOS relies on runtime
> polymorphism, where GGL relies on compile time (static polymorphism). GEOS
> is built using Java-ish constructs, where GGL is build the C++ way...
> All of this influences the runtime behavior, but there might be more
> reasons. Please note, I didn't do any thorough analysis, all of this is just
I do not know GEOS very well but I think that Hartmut is right here. GGL
uses the std-library for storage of coordinates. If I'm right, GEOS
calls a memory allocation for every point (of a polygon). And indeed GGL
uses static polymorphism. The consequence of this is also that there is
no polygon.area() function, but an area(polygon) function, taking any
polygon which fulfills the polygon concept.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geos-devel