Announcement

Collapse
No announcement yet.

GCC 11 Now Defaults To C++17 Dialect By Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Mangix View Post

    With higher standards, more and more stuff becomes constexpr, making compilation slower.

    Not the only reason but that's one of them.
    But I see no point in compiling, e.g. a C++11 project with the default standard (in this case C++17). You're likely to see warnings about deprecated stuff, or even failures due to removed constructs. Whether it is slower even with flag -std=c+11 is another story, although I can't imagine why. Maybe because the header files are exactly the same, after all, only with more guards discriminating between standards and dialects..?
    Last edited by klapaucius; 29 June 2020, 06:00 AM.

    Comment


    • #12
      Originally posted by Mangix View Post
      I was under the impression that constexpr enables compile time evaluation.
      No, it enforces compile time evaluation is possible (consteval enforces that it is also done) and allows the usage where compile time evaluation is required (in template arguments), but compilers have always tried to evaluate as much as possible at compile time, there just wasn't any cross-platform way to rely on it being done at compile time before constexpr. Compilers as much as 30 years ago already did extensive compile time evaluation of constants and expressions based on constants. Might be much older than that. Even modern C has keywords that relies on compile time evaluation (such as _Static_assert, see https://en.cppreference.com/w/c/language/_Static_assert)

      Comment


      • #13
        Originally posted by archibald View Post

        I'm sorry to say but you're mistaken here - constexpr is a keyword that allows compile-time evaluation: https://en.cppreference.com/w/cpp/language/constexpr. It can indeed slow down compilation time, but it results in runtime speedups and compile-time checking of results, so the tradeoff is generally considered worth it.
        Nope.. Try it Play round here on godbolt.org, and try to get const and constexpr to produce different code with optimizing compilers

        Comment


        • #14
          Originally posted by archibald View Post

          I'm sorry to say but you're mistaken here - constexpr is a keyword that allows compile-time evaluation: https://en.cppreference.com/w/cpp/language/constexpr. It can indeed slow down compilation time, but it results in runtime speedups and compile-time checking of results, so the tradeoff is generally considered worth it.
          Everything can slow down compilation, but constexpr often does the opposite. Evaluation is usually alot faster than multiple optimization passes and heuristics. Compiletime evaluation reduces code to a number early.

          And c++14/17 greatly improved writing such code, with C11 you were limited and often had to resort to recursion. So easier, faster to evaluate and optimize code with higher standards

          Comment


          • #15
            Originally posted by carewolf View Post
            Nope.. Try it Play round here on godbolt.org, and try to get const and constexpr to produce different code with optimizing compilers
            I've had a play around and take your point. I find it hard to reason about code once the optimiser gets involved, since it gets to change so much that the original code ends up quite detached from what's executed.

            Originally posted by discordian View Post
            Everything can slow down compilation, but constexpr often does the opposite. Evaluation is usually alot faster than multiple optimization passes and heuristics.
            Yeah, "able to slow down compilation" is a fairly weak statement - I was trying to say that whilst it might be possible for it to slow it down (perhaps at lower optimisation levels though?) the benefits are concrete.
            Last edited by archibald; 30 June 2020, 09:47 AM.

            Comment


            • #16
              Originally posted by pal666 View Post
              old code will use newer standard library, which will use newer language features which usually speed up compiling
              That's not true. The newer standard library doesn't usually use newer language features, because it has to still be compatible with C++11 and C++14 too, e.g. GCC doesn't use explicit(bool) for tuple constructors, and it doesn't use if constexpr in C++17 even when that would be faster to compile than old fashioned tag dispatching with lots of overloads.

              Compiling as a new standard definitely CAN make compilation slower, and it DOES. C++11 added dozens of new constructors to containers and tuple, and that makes overload resolution noticably slower even if you don't use any of those new constructors. C++17 adds even more new things to headers, which takes longer to parse even if you don't use them.

              Comment

              Working...
              X