Geometry Boost List: [ggl] Physical and logical structure of geometry/strategies

Subject: [ggl] Physical and logical structure of geometry/strategies
From: barend (barend.gehrels)
Date: 2010-03-14 07:36:27

Hi Mateusz,
Right, good points.
----------------------
 

> (BTW, why centroid_ has underscore suffix?)

That is noted in the source file:

// Note: when calling the namespace "centroid", it sometimes,

// somehow, in gcc, gives compilation problems (confusion with function 
centroid).

I remember we mailed about this right before review. Couldn't solve it at 
that time. Just looked again and cannot solve it.

gcc confuses namespace strategy::centroid with the free function centroid. 
Therefore it cannot define namespace centroid at that stage.

It might be able to solve it by order of include files (strategies coming 
first) but it doesn't (at least not at my place)

Which makes me realize that the name of namespace strategy::area also might 
be dangerous (though we don't have (gcc) problems there).

As far as I know these things:
boost::geometry::area (free function)
boost::geometry::strategy::area (namespace)
should never be confused by the compiler. However, for centroid it is, by 
gcc 3.4.5 and gcc 4.4, and I still don't know why. It was not always like 
this. Maybe I've made somewhere a stupid error :-) as it is only confused 
for centroid.

----------------------

> For example: boost::geometry::area::result
Like this, this is not possible and will confuse namespace area with 
function area. If there is a namespace in between, the confusion will (or at 
least should) not be there. So
boost::geometry::strategy::area::result would be theoretically OK (unless 
compiler confusions like with centroid occur).

However, I have some objections to that definition. The result would be that 
people need to declare:
boost::geometry::strategy::area::result r = 
boost::geometry::area(something);
while they are doing nothing with strategies at all, in most cases. So why 
strategy there, they will ask. The area_result is actually unrelated to 
strategies, the only thing which is going on is that it is defined by a 
strategy, but that is usually behind the screens for an end user.
So, like it was:
boost::geometry:area_result r = boost::geometry::area(something);
is for me the most logical definition.
> If it does, why not boost::geometry::strategy::traits::area ?
This is possible and might be a good idea. This is behind the screens for 
end users, so we have more flexibility there.
The question is: is it really a traits class (I realize that I commented it 
myself with 'traits' indeed). It is a structure which should be specialized 
per coordinate system, to define the default strategy for that coordinate 
system. It is perfectly possible to have strategies which are NOT 
specialized by such a trait, in fact it is not possible to specialize two of 
them for the same coordinate system.
So now that you raise this subject and that I think about it, it is not 
really a traits class.
So what would be the perfect name. I agree with you that strategy_area and 
area_result are named inconsistently (though they have different targets).
Probably the obvious solution is to name it what it is, so: 
'area_default_strategy'. This is more or less consistent with area_result, 
if you consider   'default_strategy' as one term.

An alternative is to move it to the namespace of the strategies, so:
boost::geometry::strategy::area::default_strategy // for the default 
strategy specializations per coordinate system
boost::geometry::strategy::area::area_by_triangle // for the concrete 
strategy

I favour this solution.
> 3) I have an impression that the current logical structure

> 
is to reserve namespace of boost::geometry::strategy::area

> 
for concrete strategies only, but all tools used to generate

> 
strategies like traits and metafunctions, sit on purpose in

> 
namespace boost::geometry. Am I right?
Yes that was the idea, but it might be defined differently indeed.

Regards, Barend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20100314/3cf10d96/attachment.html