|
|
Geometry : |
Subject: Re: [geometry] breaking change on transform strategies
From: Mark R Stallard (stallard_at_[hidden])
Date: 2013-11-22 17:03:17
I also noticed this change when I installed Boost 1.55 last week. My
typedef's
using strategy::transform::ublas_transformer and inverse_transformer both
failed
to compile. I was able to resolve that by reading matrix_transformers.hpp
and
comparing it to the 1.54 version. After updating my code, I found the new
template format to be more obvious and easier to read.
One related issue not mentioned yet is the doc/html pages for the two types
I mentioned here. They show the new template format, but have no
"Description"
written for the new Parameter named "CalculationType". My suggestion for
that
would be "Matrix cell type (typically double or float)". Again, I would
not
have known what "CalculationType" was supposed to mean if I had not first
read matrix_transformers.hpp.
|+| M a r k |+|
Mark Stallard
Rapid Response Development
Business Application Services
Enterprise Services Information Technology
Global Business Services
Raytheon Company
(business)
339-645-6423
(cell)
617-331-5443
stallard_at_[hidden]
235 Presidential Way
Woburn, MA 01801-1060
www.raytheon.com
This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this message
in error, please so advise the sender by reply e-mail and delete this
message. Thank you for your cooperation.
From: Bruno Lalande <bruno.lalande_at_[hidden]>
To: "Boost.Geometry library mailing list"
<geometry_at_[hidden]>
Date: 11/22/2013 04:44 PM
Subject: Re: [geometry] breaking change on transform strategies
Sent by: "Geometry" <geometry-bounces_at_[hidden]>
Hi Bernhard,
For the distance algorithm (the one I handled the same way), the advantages
for the user were more obvious. For this one I agree they're less so. Let
me first summarize what they're supposed to be:
* [for the user] More user-friendly - for distance, things like
pythagoras<Point1, Point2, CalculationType> became
pythagoras<CalculationType>
* [for us] (that was the first motivation) more flexibility within the
library - manipulating the strategies with the algo dispatch mechanism is
made easier, and some internal tricks are made irrelevant - a recent
communication with somebody wanting to contribute a change confirmed the
new approach was better
* [generally] Less template instantiations - good for compile times and to
avoid reaching number of sections limit on some implementations
Reason 2 is really the main one, as I was blocked on several developments
because of that.
But I must admit that in your case, and for this algorithms, it's less
appealing. In the case of an end user it's OK
(translate_transformer<mypoint, mypoint> would be replaced by e.g.
rotate_transformer<double, 2, 2>). But in your case you're using template
point types so it gets ugly indeed.
I've looked at the code and those template parameters are indeed needed as
class level - they are basically remaining parts of the point types that we
couldn't move down to function level. So I think the situation would be a
good candidate for maker functions (a la make_pair). This is something I
intended to try for distance strategies as well, but here I can see it's
even more relevant. Thanks to maker functions, our code could basically
become (using C++11 syntax, just replace with BOOST_AUTO otherwise or pass
the strategies directly):
auto rotate = make_rotate_transformer(...);
auto translate = make_translate_transformer(...);
bg::transform(..., rotate);
bg::transform(..., translate);
That would automatically return the right type of strategy, depending on
the type of parameters passed (so you'd need to use the same type as what
your points use, does that make the code even uglier in your situation?)
and the number of parameters (e.g. the 9 params overload would return a
strategy for points of dimension 2).
Barend: what do you think of this?
Bernhard: would this help at all?
Regards
Bruno_______________________________________________
Geometry mailing list
Geometry_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Geometry list run by mateusz at loskot.net