Boost logo

Boost :

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-08-29 14:08:55


Before doing an actual review, there are a few things I would have to
discuss.

The library appears to be quite adequate at performing operations on
dynamically-sized polygons of integral coordinates.

I wonder how difficult it would be to extend the system so that it could
work with statically-sized polygons. (the library only provides
rectangles, basically polygons 90 which a static size of 4)
I'm thinking of triangles in particular.
Also, could algorithms like triangulation eventually become part of the
library?

Still in the static vs dynamic argument, it appears points implement by
default the static coordinate lookup (the x() and y() functions) in
terms of the dynamic one (the get(orientation_2d) function).
Shouldn't it be the other way around?

The documentation says euclidean_distance was named so instead of
distance to avoid ambiguity with std::distance.
Isn't that problem simply solved by qualifying the call? Or maybe I'm
missing something?

Personally, I tend to prefer functions that return results rather than
those that take some input and modify it, since the latter require the
objects to model the mutable variant of the concept, and mutation makes
code more complex to reason about by undermining referential
transparency and equational reasoning. (part of that sentence was
copy/pasted ;)).
Couldn't a function like "center", for example, instead of taking a
point to modify, directly return some kind of simplistic expression
template, then perform the evaluation when a conversion to T is
requested, using T as an output type?

Finally, about the operator overloading for set operations, I would like
to be able to avoid pushing the namespace in the global one if possible.
I think it would be nice to have a "ref" function or something that
would make objects just behave like a reference to the original object
but within the right namespace so that the operators get picked up by ADL.
Functions that would return expression templates like discussed above
could also make their return type in the right namespace so that it gets
picked up by ADL too.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk