Subject: [ggl] Physical and logical structure of geometry/strategies
From: barend (barend.gehrels)
Date: 2010-03-14 07:36:27
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
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)
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 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 =
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
Geometry list run by mateusz at loskot.net