Subject: Re: [geometry] extensions
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-02-08 13:49:06
> Regarding lexical_cast => would probably be better to have that
> encapsulated somewhere rather than having the same #ifdef at several
> places of the code.
> 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.
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,
> 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.
Geometry list run by mateusz at loskot.net