Boost logo

Geometry :

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

Geometry list run by mateusz at