5 ms·

I know most of this trivia except where it crossed to C++, which I don't pretend to understand. And instead of a candidate having a deep knowledge of this, I wo

I know most of this trivia except where it crossed to C++, which I don't pretend to understand. And instead of a candidate having a deep knowledge of this, I would rather have the compiler refuse to compile most of the examples. Computers are good at repetitively checking things. Why should I have to?

jstimpfle 9y ago
There are some places where only the programmer can know that the undefined case doesn't happen (like integer overflow). But yeah, what purpose does it serve that the order of side effects in "a() +b()" is unspecified? I assume that's for historical reasons.
- tom_mellior 9y ago
  A fixed evaluation order may be (very slightly) less efficient than if the compiler is allowed to reorder. Consider evaluating "x + f()" when x is global and the compiler can't prove that x cannot change during execution of f. If the order of evaluation is fixed from left to right, then it must do the following: 1. load x into a register 2. spill the register holding x to the stack 3. call f 4. reload the "local" version of x from the stack 5. add On the other hand, if the order of evaluation can be chosen by the compiler, it can do this: 1. call f 2. load x into a register 3. add (Details depend on whether the caller or the callee saves x, but you get the idea.)
  - cwzwarich 9y ago
    In practice, all competitive optimizing compilers are SSA-based, and thus they fix an order of evaluation early in the compilation process. I always wondered how much performance could be gained by actually delaying decisions about evaluation order.
    - tom_mellior 9y ago
      Not sure if you're tyring to suggest that SSA-based compilers cannot do this reordering. For my example above, GCC reorders as I sketched, while Clang keeps the program order: https://godbolt.org/g/8KDvFo https://godbolt.org/g/8KDvFo I think this is done early, during lowering to a "mid-end" intermediate representation (whether SSA or not). This is the best time to do it, since the legality of this reordering is a property of the source language, which you want to forget about in the mid-end. On the other hand, in this particular example (function call vs. global variable access), I don't think there is any reason to delay this; doing the call first should never be worse than loading the global first. As for deciding other things later, instruction scheduling and global code motion can reorder a lot of things, though calls and memory accesses block many movements.
0xcde4c3db 9y ago
For C++ especially, most of these conventions and techniques co-evolved with the language, so requiring the compiler to produce an error for failing to follow them would be a breaking change. You might be able to configure your particular environment to produce more errors than the standard requires, which is what some of the mentioned warning flags are about. GCC and LLVM both support syntax like this to flag specific warnings as errors: -Werror=reorder (this specific one will error out if member variables aren't declared and initialized in the same order).
- goerz 9y ago
  I yearn for compilers that can break backwards-compatiblity and strictly enforce best practices. This should be a achieved with a relatively simple command line flag to the compiler (instead of hunting for the right combination of dozens of -Werror=*, which then still let a lot of unclean code through)
  - setr 9y ago
    Won't see widespread usage outside of learning because you can no longer trust any compiler upgrade not requiring a rewrite to your code, as it arbitrarily decides what the latest best practice. What might be useful though is something like -wall printing all flags representing current best practices, so you can have a snapshot of it when writing new code (the problem with current -wall is again potentially arbitrary changes on compiler updates as new warnings get added, if it actually did warn on everything) Then you can choose when you want to update to whatever modern best practices
    - goerz 9y ago
      That would be fine! Although, I also don't think "best practices" would be something that changes every 6 months (maybe every 5 years), and being forced by the compiler to rewrite code to keep up with best practices is absolutely a good thing! I've been the lead on a fairly large Fortran project, and we make a point to run our test suite on as many compilers as possible, with the strictest flags to avoid any kind of "undefined" behavior (which is rarer in Fortran than in C). I believe it's the only way to ensure long term maintainability.

jstimpfle 9y ago

There are some places where only the programmer can know that the undefined case doesn't happen (like integer overflow). But yeah, what purpose does it serve that the order of side effects in "a() +b()" is unspecified? I assume that's for historical reasons.

tom_mellior 9y ago
A fixed evaluation order may be (very slightly) less efficient than if the compiler is allowed to reorder. Consider evaluating "x + f()" when x is global and the compiler can't prove that x cannot change during execution of f. If the order of evaluation is fixed from left to right, then it must do the following: 1. load x into a register 2. spill the register holding x to the stack 3. call f 4. reload the "local" version of x from the stack 5. add On the other hand, if the order of evaluation can be chosen by the compiler, it can do this: 1. call f 2. load x into a register 3. add (Details depend on whether the caller or the callee saves x, but you get the idea.)
- cwzwarich 9y ago
  In practice, all competitive optimizing compilers are SSA-based, and thus they fix an order of evaluation early in the compilation process. I always wondered how much performance could be gained by actually delaying decisions about evaluation order.
  - tom_mellior 9y ago
    Not sure if you're tyring to suggest that SSA-based compilers cannot do this reordering. For my example above, GCC reorders as I sketched, while Clang keeps the program order: https://godbolt.org/g/8KDvFo https://godbolt.org/g/8KDvFo I think this is done early, during lowering to a "mid-end" intermediate representation (whether SSA or not). This is the best time to do it, since the legality of this reordering is a property of the source language, which you want to forget about in the mid-end. On the other hand, in this particular example (function call vs. global variable access), I don't think there is any reason to delay this; doing the call first should never be worse than loading the global first. As for deciding other things later, instruction scheduling and global code motion can reorder a lot of things, though calls and memory accesses block many movements.

0xcde4c3db 9y ago

For C++ especially, most of these conventions and techniques co-evolved with the language, so requiring the compiler to produce an error for failing to follow them would be a breaking change. You might be able to configure your particular environment to produce more errors than the standard requires, which is what some of the mentioned warning flags are about. GCC and LLVM both support syntax like this to flag specific warnings as errors: -Werror=reorder (this specific one will error out if member variables aren't declared and initialized in the same order).

goerz 9y ago
I yearn for compilers that can break backwards-compatiblity and strictly enforce best practices. This should be a achieved with a relatively simple command line flag to the compiler (instead of hunting for the right combination of dozens of -Werror=*, which then still let a lot of unclean code through)
- setr 9y ago
  Won't see widespread usage outside of learning because you can no longer trust any compiler upgrade not requiring a rewrite to your code, as it arbitrarily decides what the latest best practice. What might be useful though is something like -wall printing all flags representing current best practices, so you can have a snapshot of it when writing new code (the problem with current -wall is again potentially arbitrary changes on compiler updates as new warnings get added, if it actually did warn on everything) Then you can choose when you want to update to whatever modern best practices
  - goerz 9y ago
    That would be fine! Although, I also don't think "best practices" would be something that changes every 6 months (maybe every 5 years), and being forced by the compiler to rewrite code to keep up with best practices is absolutely a good thing! I've been the lead on a fairly large Fortran project, and we make a point to run our test suite on as many compilers as possible, with the strictest flags to avoid any kind of "undefined" behavior (which is rarer in Fortran than in C). I believe it's the only way to ensure long term maintainability.