Menu ▾ ▴

#5658 Include <cmath> consistently, not <math.h>

Fixed
Dan Eble
Fixed_2_21_0 (565)
Enhancement
2020-01-17
2020-01-09
Dan Eble
No

In the past, we had problems with std::isinf and std::isnan not being
provided by <cmath> because they are C++11 features, so we were
including <math.h> in some places.

Now, we are using C++11. Because the code is also graced with
using namespace std; all over the place (see issue 4550), ambiguity
may arise. Using <cmath> consistently should improve the situation.

https://codereview.appspot.com/569220043

Discussion

  • Dan Eble

    Dan Eble - 2020-01-10

    Remove our own definition of isinf()

    https://codereview.appspot.com/569220043

     

  • Anonymous

    Anonymous - 2020-01-10
    • Description has changed:

    Diff:
    • Needs: -->
    • Patch: new --> review
    • Type: --> Enhancement
     

  • Anonymous

    Anonymous - 2020-01-10

    Passes make, make test-baseline and a full make doc.

     

  • Dan Eble

    Dan Eble - 2020-01-11

    Qualify isinf, isnan, isfinite with std::

    https://codereview.appspot.com/569220043

     

  • Dan Eble

    Dan Eble - 2020-01-11

    Cleanup: !isinf && !isnan == isfinite

    https://codereview.appspot.com/569220043

     

  • Anonymous

    Anonymous - 2020-01-12
    • Needs: -->
    • Patch: new --> review
    • Type: --> Enhancement
     

  • Anonymous

    Anonymous - 2020-01-12

    Passes make, make test-baseline and a full make doc.

     

  • Dan Eble

    Dan Eble - 2020-01-12
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,9 +1,9 @@
 In the past, we had problems with std::isinf and std::isnan not being
-provided by &lt;cmath&gt; because they are C++11 features, so we were
-including &lt;math.h&gt; in some places.
+provided by `&lt;cmath&gt;` because they are C++11 features, so we were
+including `&lt;math.h&gt;` in some places.

 Now, we are using C++11.  Because the code is also graced with
-&#34;using namespace std;&#34; all over the place (see issue 4550), ambiguity
-may arise.  Using &lt;cmath&gt; consistently should improve the situation.
+`using namespace std;` all over the place (see issue 4550), ambiguity
+may arise.  Using `&lt;cmath&gt;` consistently should improve the situation.

 https://codereview.appspot.com/569220043
     

  • Anonymous

    Anonymous - 2020-01-14
    • Patch: review --> countdown
     

  • Anonymous

    Anonymous - 2020-01-14

    Patch on countdown for Jan 16th

     

  • Anonymous

    Anonymous - 2020-01-16
    • Patch: countdown --> push
     

  • Anonymous

    Anonymous - 2020-01-16

    Patch counted down - please push

     

  • Dan Eble

    Dan Eble - 2020-01-17
    • labels: --> Fixed_2_21_0
    • status: Started --> Fixed
    • Patch: push -->
     

  • Dan Eble

    Dan Eble - 2020-01-17 
    commit 20c9983553e9883a899d7e10156a0e34b8900648 (HEAD -> dev/issue-5658-include-cmath, origin/staging)
Author: Dan Eble <nine.fierce.ballads@gmail.com>
Date:   Fri Jan 10 20:53:26 2020 -0500

    Issue 5658/3: Cleanup: !isinf && !isnan == isfinite

    commit bb711884c61975474387ae6da10be378c129d3b4
Author: Dan Eble <nine.fierce.ballads@gmail.com>
Date:   Fri Jan 10 18:54:20 2020 -0500

    Issue 5658/2: Qualify isinf, isnan, isfinite with std::

    This is necessary because we have seen an implementation of the standard
    library that defines ::isinf when certain headers other than math.h are
    included, so just avoiding math.h is not enough.

    commit 0376c35dbd5b9917fdfb61c80a94ccb3d6b0a997
Author: Dan Eble <nine.fierce.ballads@gmail.com>
Date:   Thu Jan 9 16:40:46 2020 -0500

    Issue 5658/1: Include <cmath> consistently, not <math.h>

    In the past, we had problems with std::isinf and std::isnan not being
    provided by <cmath> because they are C++11 features, so we were
    including <math.h> in some places, and even potentially defining our
    own isinf().

    Now, we are using C++11.  Because the code is also graced with
    "using namespace std;" all over the place (see issue 4550), ambiguity
    may arise.  Using <cmath> consistently and removing our local definition
    of isinf() should improve the situation.