Re: Deprecate the use of plain pointers as standard container iterators

* Thorsten Ottosen:


Titled "Crazy ideas", but they're not at all crazy. Change the title.

Also, I think it would be a good idea to add inclusion of pi and e
constants in <cmath> and/or <limits>.

There is existing practice for pi: having M_PI in <math.h>, but the
uppercase stems from the C heritage and may conflict with macro naming.

Here's a list of <math.h> constants from one very popular compiler:

   M_E e 2.71828182845904523536
   M_LOG2E log2(e) 1.44269504088896340736
   M_LOG10E log10(e) 0.434294481903251827651
   M_LN2 ln(2) 0.693147180559945309417
   M_LN10 ln(10) 2.30258509299404568402
   M_PI pi 3.14159265358979323846
   M_PI_2 pi/2 1.57079632679489661923
   M_PI_4 pi/4 0.785398163397448309616
   M_1_PI 1/pi 0.318309886183790671538
   M_2_PI 2/pi 0.636619772367581343076
   M_2_SQRTPI 2/sqrt(pi) 1.12837916709551257390
   M_SQRT2 sqrt(2) 1.41421356237309504880
   M_SQRT1_2 1/sqrt(2) 0.707106781186547524401

I suggest adding the logically missing constants (of the same form as
above) and using a nesting class like

   namespace std
   {
       template< typename FloatingPointType >
       struct constant
       {
           static const FloatingPointType e = ...;
           static const FloatingPointType log2e = ...;
           static const FloatingPointType log10e = ...;
           static const FloatingPointType ln2 = ...;
           static const FloatingPointType ln10 = ...;
           static const FloatingPointType pi = ...;
           static const FloatingPointType half_pi = ...;
           static const FloatingPointType quarter_pi = ...;
           static const FloatingPointType inv_pi = ...;
           static const FloatingPointType two_inv_pi = ...;
           static const FloatingPointType sqrt_pi = ...;
           static const FloatingPointType inv_sqrt_pi = ...;
           static const FloatingPointType two_inv_sqrt_pi = ...;
           static const FloatingPointType sqrt_two = ...;
           static const FloatingPointType inv_sqrt_two = ...;
       };
   }

where having it as a template allows extern linkage compile time
constants (if that matters) and the compiler's best precision per type.

Usage would be like

    typedef std::constant<double> DoubleC;

    ...
    std::cout << DoubleC::pi << std::endl;

Perhaps somebody will suggest placing the constants in
std::numeric_limits. After all, some other "constants" live there.
However, those are "constants" relating to each type's limits, and
furthermore, people refraing from using std::numeric_limits (except in
template code) because of the verbosity and non-constantness: INT_MAX
(short constant), not std::numeric_limits<int>::max() (long call).

Motivation: (1) get the compiler's best precision, (2) avoid errors, (3)
increase readability and writeability of code, (4) ease the process of
analyzing code (a good IDE can give automatic tooltip for e.g.
std::d::pi), and, not the least, (5) it's not just silly but plain
stupid to not have pi and e constants, it's "the language with no pi".

When I've mentioned this earlier the answer has always been that
nobody's proposed it. So, why not include it in the proposal list?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]