Geometry Boost List: Re: [geometry] breaking change on transform strategies

Subject: Re: [geometry] breaking change on transform strategies
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-11-24 12:49:15

Hi,

Right, sorry that this change did not make the Release Notes. It is 
indeed a breaking change.

There has been send a clear mail about this but of course I agree that 
is not enough.

http://boost-geometry.203548.n3.nabble.com/breaking-change-on-transform-strategies-td4025494.html

Mark R Stallard wrote On 22-11-2013 23:03:
>
> 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.
>

Yes, besides the release notes the docs have not been updated. All this 
has slipped through, sorry again.

> ------------------------------------------------------------------------
>
> 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.

For transform: some things could not be done in the past (up to 1.54). 
It was not possible to (once) define a strategy and then apply the 
transform function with any point-type afterwards. That was inconvenient.

For the rest it aligned with the other actions.

However, indeed we could not get rid of everything, because a matrix 
must have a type (e.g. double) and some dimensions to store the matrix 
itself. They cannot be decuded at a call, that is too late, they have to 
be instantiated first.

>
> 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?

The way you (Bernhard) did this (using coordinate_type and dimension) is 
OK. But indeed larger and more complex.

The additional functions of Bruno to make this easier sound good to me.

I hope that my change was OK and in line with the other changes on 
strategies, the point-type, formerly specified, was just used to get the 
information (coordinate type, dimensions, coordinate system) from, it 
was not really used inside the strategy. Now this is moved to 
user-level, the change itself was actually small (the library did not 
change a lot). But it is now a bit more flexible, for those who use that.

I cannot remember why I did not add this immediately afterwards inside 
the release notes and the docs, that would have been more convenient. 
Anyway we can do that now (as soon git is up and running), because there 
are also many users skipping a version.

Regards, Barend