Why isn't abs constexpr?












12















In <cinttypes>, since C++11, there are the following two overloads:



std::intmax_t abs( std::intmax_t n );
std::intmax_t imaxabs( std::intmax_t n );


Why aren't those two functions constexpr?










share|improve this question


















  • 5





    @BasileStarynkevitch: Can you explain one of these compatibility reasons?

    – Lightness Races in Orbit
    Dec 30 '14 at 16:14






  • 5





    @BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

    – IdeaHat
    Dec 30 '14 at 16:16






  • 7





    abs is a C99 function. And C99 has no idea of constexpr

    – Basile Starynkevitch
    Dec 30 '14 at 16:32






  • 17





    There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

    – Marc Glisse
    Dec 30 '14 at 16:40






  • 3





    abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

    – edmz
    Dec 30 '14 at 17:02


















12















In <cinttypes>, since C++11, there are the following two overloads:



std::intmax_t abs( std::intmax_t n );
std::intmax_t imaxabs( std::intmax_t n );


Why aren't those two functions constexpr?










share|improve this question


















  • 5





    @BasileStarynkevitch: Can you explain one of these compatibility reasons?

    – Lightness Races in Orbit
    Dec 30 '14 at 16:14






  • 5





    @BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

    – IdeaHat
    Dec 30 '14 at 16:16






  • 7





    abs is a C99 function. And C99 has no idea of constexpr

    – Basile Starynkevitch
    Dec 30 '14 at 16:32






  • 17





    There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

    – Marc Glisse
    Dec 30 '14 at 16:40






  • 3





    abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

    – edmz
    Dec 30 '14 at 17:02
















12












12








12


1






In <cinttypes>, since C++11, there are the following two overloads:



std::intmax_t abs( std::intmax_t n );
std::intmax_t imaxabs( std::intmax_t n );


Why aren't those two functions constexpr?










share|improve this question














In <cinttypes>, since C++11, there are the following two overloads:



std::intmax_t abs( std::intmax_t n );
std::intmax_t imaxabs( std::intmax_t n );


Why aren't those two functions constexpr?







c++ c++11 constexpr






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 30 '14 at 16:05









ShoeShoe

59.2k26123215




59.2k26123215








  • 5





    @BasileStarynkevitch: Can you explain one of these compatibility reasons?

    – Lightness Races in Orbit
    Dec 30 '14 at 16:14






  • 5





    @BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

    – IdeaHat
    Dec 30 '14 at 16:16






  • 7





    abs is a C99 function. And C99 has no idea of constexpr

    – Basile Starynkevitch
    Dec 30 '14 at 16:32






  • 17





    There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

    – Marc Glisse
    Dec 30 '14 at 16:40






  • 3





    abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

    – edmz
    Dec 30 '14 at 17:02
















  • 5





    @BasileStarynkevitch: Can you explain one of these compatibility reasons?

    – Lightness Races in Orbit
    Dec 30 '14 at 16:14






  • 5





    @BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

    – IdeaHat
    Dec 30 '14 at 16:16






  • 7





    abs is a C99 function. And C99 has no idea of constexpr

    – Basile Starynkevitch
    Dec 30 '14 at 16:32






  • 17





    There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

    – Marc Glisse
    Dec 30 '14 at 16:40






  • 3





    abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

    – edmz
    Dec 30 '14 at 17:02










5




5





@BasileStarynkevitch: Can you explain one of these compatibility reasons?

– Lightness Races in Orbit
Dec 30 '14 at 16:14





@BasileStarynkevitch: Can you explain one of these compatibility reasons?

– Lightness Races in Orbit
Dec 30 '14 at 16:14




5




5





@BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

– IdeaHat
Dec 30 '14 at 16:16





@BasileStarynkevitch I don't buy that. Given a compatible compiler, a constexpr piece of code will work the same as it used, i.e. when passed in non-constexpr values it will return a non-constexpr. If it preferable to compatible to not make these functions constexpr (or alteast with constexpr overloads) then it would be preferable to not include move instructors for vector. Being that this uses namespaces (so is not C) and is a header provided only in C++11, I would like to see constexpr overlaods.

– IdeaHat
Dec 30 '14 at 16:16




7




7





abs is a C99 function. And C99 has no idea of constexpr

– Basile Starynkevitch
Dec 30 '14 at 16:32





abs is a C99 function. And C99 has no idea of constexpr

– Basile Starynkevitch
Dec 30 '14 at 16:32




17




17





There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

– Marc Glisse
Dec 30 '14 at 16:40





There are a lot of functions that could be constexpr and are not (yet). More functions will slowly become constexpr with each revision of the standard. Feel free to participate in that process (instructions on isocpp.org).

– Marc Glisse
Dec 30 '14 at 16:40




3




3





abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

– edmz
Dec 30 '14 at 17:02







abs is not constexpr because the standard decided so. I think this is the wrong place to ask why. What I can say is that if you really need a constexpr abs, write your own one. You can't go wrong.

– edmz
Dec 30 '14 at 17:02














3 Answers
3






active

oldest

votes


















4














I can't give a good reason for why abs couldn't be constexpr and apparently neither can gcc. When I use gcc 4.9.2 with this program:



#include <cstdlib>
#include <cinttypes>
#include <cassert>

constexpr intmax_t abs3 = std::abs(3);
constexpr intmax_t absneg3 = std::abs(-3);
int main()
{
assert(abs3 == absneg3);
}


it compiles and runs to completion with no warnings or errors. You can try it here. However, clang++ (version 3.5.0) throws a compile-time error:




abs.cpp:6:20: error: constexpr variable 'abs3' must be initialized by a constant expression.




I think that clang++ actually gets it right here, because in section 27.9.2 [c.files] of the 2011 standard, it says:




The contents of header are the same as the Standard C Library header , with the following changes:



— the header includes the header instead of , and



— if and only if the type intmax_t designates an extended integer type (3.9.1), the following function
signatures are added:



intmax_t abs(intmax_t);



imaxdiv_t div(intmax_t, intmax_t);



which shall have the same semantics as the function signatures intmax_t imaxabs(intmax_t) and
imaxdiv_t imaxdiv(intmax_t, intmax_t), respectively.




In the current working draft of the C++ standard, as in the published 2014 version, it says in section 17.6.5.6 [constexpr.functions]:




This standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation shall not declare any standard library function signature as constexpr except for those where it
is explicitly required.




So the result, for now, is that these functions are still not constexpr according to the standard (which you knew) but they could be, as demonstrated by the gcc compiler.






share|improve this answer
























  • For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

    – Shafik Yaghmour
    Nov 13 '15 at 20:29











  • In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

    – leek
    Nov 22 '18 at 23:04





















1














The simple explanation is probably that nobody went through every function listed as part of the standard library, and updated the entry to make it constexpr.



Updating a standard is a process involving human effort to propose changes and get those proposals reviewed and accepted. And that means, when a new feature is added - and constexpr is a new feature - not everything else is automagically updated to use that feature. This particular case may well be updated in a future evolution of the standard - if some people take on the - often thankless - task of proposing the set of changes, some other people take on the task of reviewing it, and convincing those with voting power on the committee to accept it.






share|improve this answer































    0














    It has been proposed in P0533:




    A function in <cmath> shall be declared
    constexpr if and only if:




    1. When taken to act on the set of rational numbers,
      the function is closed (excluding division by zero);

    2. The function does not modify any of its arguments
      which have external visibility;

    3. The function is not strongly dependent on the
      rounding mode.


    By means of a brief illustration, abs satisfies all three criteria; however, functions such as exp, sqrt, cos, sin fall foul of the first criterion and so are excluded as constexpr candidates. Finally, as discussed above, nearbyint fails the final criterion.







    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27708629%2fwhy-isnt-abs-constexpr%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      I can't give a good reason for why abs couldn't be constexpr and apparently neither can gcc. When I use gcc 4.9.2 with this program:



      #include <cstdlib>
      #include <cinttypes>
      #include <cassert>

      constexpr intmax_t abs3 = std::abs(3);
      constexpr intmax_t absneg3 = std::abs(-3);
      int main()
      {
      assert(abs3 == absneg3);
      }


      it compiles and runs to completion with no warnings or errors. You can try it here. However, clang++ (version 3.5.0) throws a compile-time error:




      abs.cpp:6:20: error: constexpr variable 'abs3' must be initialized by a constant expression.




      I think that clang++ actually gets it right here, because in section 27.9.2 [c.files] of the 2011 standard, it says:




      The contents of header are the same as the Standard C Library header , with the following changes:



      — the header includes the header instead of , and



      — if and only if the type intmax_t designates an extended integer type (3.9.1), the following function
      signatures are added:



      intmax_t abs(intmax_t);



      imaxdiv_t div(intmax_t, intmax_t);



      which shall have the same semantics as the function signatures intmax_t imaxabs(intmax_t) and
      imaxdiv_t imaxdiv(intmax_t, intmax_t), respectively.




      In the current working draft of the C++ standard, as in the published 2014 version, it says in section 17.6.5.6 [constexpr.functions]:




      This standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation shall not declare any standard library function signature as constexpr except for those where it
      is explicitly required.




      So the result, for now, is that these functions are still not constexpr according to the standard (which you knew) but they could be, as demonstrated by the gcc compiler.






      share|improve this answer
























      • For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

        – Shafik Yaghmour
        Nov 13 '15 at 20:29











      • In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

        – leek
        Nov 22 '18 at 23:04


















      4














      I can't give a good reason for why abs couldn't be constexpr and apparently neither can gcc. When I use gcc 4.9.2 with this program:



      #include <cstdlib>
      #include <cinttypes>
      #include <cassert>

      constexpr intmax_t abs3 = std::abs(3);
      constexpr intmax_t absneg3 = std::abs(-3);
      int main()
      {
      assert(abs3 == absneg3);
      }


      it compiles and runs to completion with no warnings or errors. You can try it here. However, clang++ (version 3.5.0) throws a compile-time error:




      abs.cpp:6:20: error: constexpr variable 'abs3' must be initialized by a constant expression.




      I think that clang++ actually gets it right here, because in section 27.9.2 [c.files] of the 2011 standard, it says:




      The contents of header are the same as the Standard C Library header , with the following changes:



      — the header includes the header instead of , and



      — if and only if the type intmax_t designates an extended integer type (3.9.1), the following function
      signatures are added:



      intmax_t abs(intmax_t);



      imaxdiv_t div(intmax_t, intmax_t);



      which shall have the same semantics as the function signatures intmax_t imaxabs(intmax_t) and
      imaxdiv_t imaxdiv(intmax_t, intmax_t), respectively.




      In the current working draft of the C++ standard, as in the published 2014 version, it says in section 17.6.5.6 [constexpr.functions]:




      This standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation shall not declare any standard library function signature as constexpr except for those where it
      is explicitly required.




      So the result, for now, is that these functions are still not constexpr according to the standard (which you knew) but they could be, as demonstrated by the gcc compiler.






      share|improve this answer
























      • For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

        – Shafik Yaghmour
        Nov 13 '15 at 20:29











      • In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

        – leek
        Nov 22 '18 at 23:04
















      4












      4








      4







      I can't give a good reason for why abs couldn't be constexpr and apparently neither can gcc. When I use gcc 4.9.2 with this program:



      #include <cstdlib>
      #include <cinttypes>
      #include <cassert>

      constexpr intmax_t abs3 = std::abs(3);
      constexpr intmax_t absneg3 = std::abs(-3);
      int main()
      {
      assert(abs3 == absneg3);
      }


      it compiles and runs to completion with no warnings or errors. You can try it here. However, clang++ (version 3.5.0) throws a compile-time error:




      abs.cpp:6:20: error: constexpr variable 'abs3' must be initialized by a constant expression.




      I think that clang++ actually gets it right here, because in section 27.9.2 [c.files] of the 2011 standard, it says:




      The contents of header are the same as the Standard C Library header , with the following changes:



      — the header includes the header instead of , and



      — if and only if the type intmax_t designates an extended integer type (3.9.1), the following function
      signatures are added:



      intmax_t abs(intmax_t);



      imaxdiv_t div(intmax_t, intmax_t);



      which shall have the same semantics as the function signatures intmax_t imaxabs(intmax_t) and
      imaxdiv_t imaxdiv(intmax_t, intmax_t), respectively.




      In the current working draft of the C++ standard, as in the published 2014 version, it says in section 17.6.5.6 [constexpr.functions]:




      This standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation shall not declare any standard library function signature as constexpr except for those where it
      is explicitly required.




      So the result, for now, is that these functions are still not constexpr according to the standard (which you knew) but they could be, as demonstrated by the gcc compiler.






      share|improve this answer













      I can't give a good reason for why abs couldn't be constexpr and apparently neither can gcc. When I use gcc 4.9.2 with this program:



      #include <cstdlib>
      #include <cinttypes>
      #include <cassert>

      constexpr intmax_t abs3 = std::abs(3);
      constexpr intmax_t absneg3 = std::abs(-3);
      int main()
      {
      assert(abs3 == absneg3);
      }


      it compiles and runs to completion with no warnings or errors. You can try it here. However, clang++ (version 3.5.0) throws a compile-time error:




      abs.cpp:6:20: error: constexpr variable 'abs3' must be initialized by a constant expression.




      I think that clang++ actually gets it right here, because in section 27.9.2 [c.files] of the 2011 standard, it says:




      The contents of header are the same as the Standard C Library header , with the following changes:



      — the header includes the header instead of , and



      — if and only if the type intmax_t designates an extended integer type (3.9.1), the following function
      signatures are added:



      intmax_t abs(intmax_t);



      imaxdiv_t div(intmax_t, intmax_t);



      which shall have the same semantics as the function signatures intmax_t imaxabs(intmax_t) and
      imaxdiv_t imaxdiv(intmax_t, intmax_t), respectively.




      In the current working draft of the C++ standard, as in the published 2014 version, it says in section 17.6.5.6 [constexpr.functions]:




      This standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation shall not declare any standard library function signature as constexpr except for those where it
      is explicitly required.




      So the result, for now, is that these functions are still not constexpr according to the standard (which you knew) but they could be, as demonstrated by the gcc compiler.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Apr 5 '15 at 12:47









      EdwardEdward

      4,97111946




      4,97111946













      • For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

        – Shafik Yaghmour
        Nov 13 '15 at 20:29











      • In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

        – leek
        Nov 22 '18 at 23:04





















      • For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

        – Shafik Yaghmour
        Nov 13 '15 at 20:29











      • In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

        – leek
        Nov 22 '18 at 23:04



















      For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

      – Shafik Yaghmour
      Nov 13 '15 at 20:29





      For more details re gcc and match functions treated as constexpr. gcc allowed this since they thought this was going to be allowed but it was not.

      – Shafik Yaghmour
      Nov 13 '15 at 20:29













      In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

      – leek
      Nov 22 '18 at 23:04







      In Proposal P0533, it is stated that GCC has taken the lead as the "State of the Art" in defining constexpr functions in <cmath>.

      – leek
      Nov 22 '18 at 23:04















      1














      The simple explanation is probably that nobody went through every function listed as part of the standard library, and updated the entry to make it constexpr.



      Updating a standard is a process involving human effort to propose changes and get those proposals reviewed and accepted. And that means, when a new feature is added - and constexpr is a new feature - not everything else is automagically updated to use that feature. This particular case may well be updated in a future evolution of the standard - if some people take on the - often thankless - task of proposing the set of changes, some other people take on the task of reviewing it, and convincing those with voting power on the committee to accept it.






      share|improve this answer




























        1














        The simple explanation is probably that nobody went through every function listed as part of the standard library, and updated the entry to make it constexpr.



        Updating a standard is a process involving human effort to propose changes and get those proposals reviewed and accepted. And that means, when a new feature is added - and constexpr is a new feature - not everything else is automagically updated to use that feature. This particular case may well be updated in a future evolution of the standard - if some people take on the - often thankless - task of proposing the set of changes, some other people take on the task of reviewing it, and convincing those with voting power on the committee to accept it.






        share|improve this answer


























          1












          1








          1







          The simple explanation is probably that nobody went through every function listed as part of the standard library, and updated the entry to make it constexpr.



          Updating a standard is a process involving human effort to propose changes and get those proposals reviewed and accepted. And that means, when a new feature is added - and constexpr is a new feature - not everything else is automagically updated to use that feature. This particular case may well be updated in a future evolution of the standard - if some people take on the - often thankless - task of proposing the set of changes, some other people take on the task of reviewing it, and convincing those with voting power on the committee to accept it.






          share|improve this answer













          The simple explanation is probably that nobody went through every function listed as part of the standard library, and updated the entry to make it constexpr.



          Updating a standard is a process involving human effort to propose changes and get those proposals reviewed and accepted. And that means, when a new feature is added - and constexpr is a new feature - not everything else is automagically updated to use that feature. This particular case may well be updated in a future evolution of the standard - if some people take on the - often thankless - task of proposing the set of changes, some other people take on the task of reviewing it, and convincing those with voting power on the committee to accept it.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 5 '15 at 13:23









          PeterPeter

          27.5k32155




          27.5k32155























              0














              It has been proposed in P0533:




              A function in <cmath> shall be declared
              constexpr if and only if:




              1. When taken to act on the set of rational numbers,
                the function is closed (excluding division by zero);

              2. The function does not modify any of its arguments
                which have external visibility;

              3. The function is not strongly dependent on the
                rounding mode.


              By means of a brief illustration, abs satisfies all three criteria; however, functions such as exp, sqrt, cos, sin fall foul of the first criterion and so are excluded as constexpr candidates. Finally, as discussed above, nearbyint fails the final criterion.







              share|improve this answer




























                0














                It has been proposed in P0533:




                A function in <cmath> shall be declared
                constexpr if and only if:




                1. When taken to act on the set of rational numbers,
                  the function is closed (excluding division by zero);

                2. The function does not modify any of its arguments
                  which have external visibility;

                3. The function is not strongly dependent on the
                  rounding mode.


                By means of a brief illustration, abs satisfies all three criteria; however, functions such as exp, sqrt, cos, sin fall foul of the first criterion and so are excluded as constexpr candidates. Finally, as discussed above, nearbyint fails the final criterion.







                share|improve this answer


























                  0












                  0








                  0







                  It has been proposed in P0533:




                  A function in <cmath> shall be declared
                  constexpr if and only if:




                  1. When taken to act on the set of rational numbers,
                    the function is closed (excluding division by zero);

                  2. The function does not modify any of its arguments
                    which have external visibility;

                  3. The function is not strongly dependent on the
                    rounding mode.


                  By means of a brief illustration, abs satisfies all three criteria; however, functions such as exp, sqrt, cos, sin fall foul of the first criterion and so are excluded as constexpr candidates. Finally, as discussed above, nearbyint fails the final criterion.







                  share|improve this answer













                  It has been proposed in P0533:




                  A function in <cmath> shall be declared
                  constexpr if and only if:




                  1. When taken to act on the set of rational numbers,
                    the function is closed (excluding division by zero);

                  2. The function does not modify any of its arguments
                    which have external visibility;

                  3. The function is not strongly dependent on the
                    rounding mode.


                  By means of a brief illustration, abs satisfies all three criteria; however, functions such as exp, sqrt, cos, sin fall foul of the first criterion and so are excluded as constexpr candidates. Finally, as discussed above, nearbyint fails the final criterion.








                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 22 '18 at 23:02









                  leekleek

                  499410




                  499410






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27708629%2fwhy-isnt-abs-constexpr%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Costa Masnaga

                      Fotorealismo

                      Sidney Franklin