Geometry Boost List: Re: [geometry] extensions

Subject: Re: [geometry] extensions
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-02-08 13:49:06

Hi Bruno,

>
> Regarding lexical_cast => would probably be better to have that 
> encapsulated somewhere rather than having the same #ifdef at several 
> places of the code.

Yep. Agreed.

>
> Regarding constants => So we assume that the other compilers will be 
> clever enough to figure out that it's a constant and make it static? 
> If the TI compiler is flawed enough not to manage constants as the 
> standard states, we shouldn't expect all the other compiles to go 
> *beyond* the standard and make a non-static variable static.

Good point.

I believe that our normal convention is to have things "const" in these 
cases, and not also "static".

But: this is ported C code: it is ported from proj4, and part of it is 
automatically converted. This part (adjlon/pj_init) is manually 
converted, but not really completely worked through. So that is one of 
the reasons they are still in the extensions and not in the Release branch.

>
> Also, Boost.Math already has those constants:
>
> constants/constants.hpp:  BOOST_DEFINE_MATH_CONSTANT(pi, 
> 3.1415926535897932384626433832...)
> constants/constants.hpp:  BOOST_DEFINE_MATH_CONSTANT(two_pi, 
> 6.2831853071795864769252867665590057683943388015061, 0, 0)

Sure we can reuse them. That's to say, Boost.Geometry did (does) have an 
own math::pi<T>() but that is because of templated numeric types (e.g. 
ttmath). Those were not possible to define in Boost.Math. John Maddock 
has said to help that in Boost.Math and I believe that has very recently 
been done (did not try it until now). But that was not yet released in 
the Release branch (when I looked last time).

So this can go indeed, and our geometry::math::pi can go either (or 
redirect to Boost.Math) as always was the intention.

Regards, Barend