Thread

1. wahern · 1789747013 · focus · HN ↗

   > When both conditions are met, the loop body is replaced with a call to std::this_thread::yield(). This gives execution of the loop the forward-progress semantics it previously lacked.

   That's the epitome of the hidden code downside that Linus and many others dislike about C++. For constructors and destructors it's somewhat unavoidable and not so random, though Rust does better at limiting the blast radius of non-local code, at least in the drop case.

   If they didn't want to adopt the C11 rule, the C++ committee should've explored a rule that required the compiler to emit a diagnostic or error for trivial loops (whether as defined by C11 or otherwise), requiring the programmer to explicitly insert ::yield or similar. No hidden code, and less opportunity for the compiler to do surprising things.

   The C committee has been rigorously enumerating UB cases in the standard and addressing each case in turn, often by requiring a diagnostic, error, or by turning it into implemention defined behavior. But inserting code like that would be unthinkable.

   1. kevin_thibedeau · 1789769126 · focus · HN ↗

      The C++ committee has a habit of thumbing its nose at standard practice. They intentionally broke bitwise operators on volatiles because they wanted to be impose their atomic religion everywhere. Then they had to walk that back after they broke every embedded library directly manipulating hardware registers.

      Empty infinite loops are also commonplace in embedded C once main is done with init and within exception handlers. They don't care about anything beyond their narrow systems programming worldview.

      1. 112233 · 1789786139 · focus · HN ↗

         By narrow luck compiler writers so far have been the sane bunch, and have ignored C++ committee on many important points. Thus we still have explicitly non-conformant things like -fno-exceptions that lets one use C++ compiler on embedded.

         But I wonder how long that can last, with the way C++ is going.

         At one point, it will make practical sense to update codebase to some other language, rather than keep fighting this one

         1. pjmlp · 1789798036 · focus · HN ↗

            I have been saying that C++23, or maybe C++26 due to reflection, will eventually be the last standard that actually matters.

            For a large number of C++ users, it boils down to what it offers beyond C, but not to the extent WG21 is driving it since C++20.

            Also the major surviving three compilers have lost wind on their sails as the corporations sponsoring their development have switched focus to other compiled languages.

            Other than the whole security debate, there are no features that would make C++ significantly better for LLVM, GCC, CLR, V8, CUDA,.. improvements.

            In fact, some of those projects still require C++17.

            If this sounds strange, how many care nowadays about ISO Fortran 2023, or ISO COBOL 2023, despite the amount of software written in them powering many busisesses, or Python libraries even, e.g. SciPy.

            Or even with C, almost 20 years later many still reach out to C99, ignoring everything else.

            1. ilayn · 1789803300 · focus · HN ↗

               Not to take away from your points; SciPy is now Fortran-free completely[0] (we are also requiring C++17 at most). NumPy never had it. BLAS is all C/Assembly in all optimized vendors. For LAPACK we are working on it [1].

               Once there is enough pain, none of the talking points matter for any language. They don't and can't die but linger. I fear that time for C family might come in a decade which would be a shame given how magical Cpp compilers are, all that effort folks pouring in.

               [0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18566" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18566 [1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;ilayn&#x2F;semicolon-lapack" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ilayn&#x2F;semicolon-lapack

               1. MaxBarraclough · 1790365100 · focus · HN ↗

                  Is there any significant performance difference?

                  1. ilayn · 1790619131 · focus · HN ↗

                     Not really, all competitive compilers saturated to the same performance. Often Fortran and &quot;restrict&quot; sprinkled C compile to the same command set.

Unofficial Hacker News client; not affiliated with Y Combinator.