3 ms·

Compilers are not currently allowed to do it if “failure” is in the form of an abort from an inlined function, as in the case of .at(),

• deleted 8y ago
  [deleted]
• Dylan16807 8y ago
  Ah, so the compiler doesn't understand it's a failure, and just sees normal program flow that it can't alter. That's a tricky thing to solve, yeah. At best, under current semantics, the compiler could emit a fast loop and a slow loop, and pick which one using an initial bounds check. But that's extremely awkward at best... Automatically handling the bounds check upfront is a type of control flow that's halfway between normal exceptions and undefined behavior, that C++ doesn't really grok.
  • celrod 8y ago
    When I dabbled in gfortran, a feature I liked was that while no bounds-checking is the default, run time bounds-checks can be enabled with "-fcheck=bounds" or "-fcheck=all", which can be handy while developing/testing code. Alternatively, Julia has a macro "@inbounds" which disables checks, but this involves going through and annotating code after testing. You can also start Julia with the options "--check-bounds={yes|no}" to override declarations. Running testsuites enables all checks. Seems like it would be handy if these checks could be elided by defining a macro. Any reason this isn't done? The performance cost is often much higher than the time spent repeatedly checking bounds. It tends to defeat the auto-vectorizer. Another workaround is to manually check bounds before the loop. This lets the compiler prove all bounds checks pass if it gets to the loop, and solves the problem. I do wish that sort of thing could be automatic.
• 0815test 8y ago
  If that's the semantics you want, why not just add a check at the beginning of the loop? Compilers could add a warning advising the developer to do this if she doesn't care about partial results, anytime that they can't fully eliminate an .at() bounds check inside a loop.