Geometry Boost List: Re: [geometry] extensions INCLUDING BREAKING CHANGE

Subject: Re: [geometry] extensions INCLUDING BREAKING CHANGE
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-03-04 06:27:00

Hi List, Kris,

Herewith the report on these suggestions:

On 7-2-2012 17:51, Krzysztof Czainski wrote:
>
> First of all, I think I read in boost guidelines, that it is 
> discouraged that a class and namespace enclosing it have the same 
> name. And in such cases, the convention is for the namespace to be 
> named in plural. So I suggest to rename the namespace 
> boost::geometry::projection to projections. I did not prepare a patch 
> for that ;-)

Done. As said this is a breaking change, all using programs should 
update "boost::geometry::projection::" to "boost::geometry::projections::"

>
> Secondly, I wanted to remove the dependency on boost/lexical_cast.hpp. 
> I noticed that BOOST_GEOMETRY_NO_LEXICAL_CAST is already used in some 
> parts of Boost.Geometry, so I just added the use of this to other 
> places, and no_lexical_cast.patch contains the changes.

This patch is applied. Note that Bruno suggested to solve this more 
structurally and I agree with that. But this was effectively a one line 
change in one file so to finish with this action point, it is already 
done. Will be continued.

>
> Next, I work with a Texas Instruments compiler, which has this defect, 
> that static local variables of inline functions are not resolved to a 
> single instance, and it warns about it. So I made two minor changes: 
> static_inline.patch. I think they wouldn't hurt in any case, but I 
> could be wrong here.

This patch is applied. Note that immediately after this I changed PI to 
boost::math::constants::pi<double>() and similar, I think TI compiler 
accepts that.

>
> And lastly, I encountered a macro problem - another defect of my 
> compiler - it has a #define cosl cos, so there are problems with local 
> variables named cosl. cosl.patch.

This patch is applied and the conversion program is updated. Besides 
that I did run it on the latest proj trunk (no big differences though) 
so it is up-to-date again. The new proj (I think in preparation for 4.8) 
defines 5 additional projections which are not yet supported.

Kris, thanks again for these patches and suggestions. Will now continue 
with your second batch ;-)

Regards, Barend