In fact, the standard reflects what is happening in the field. So, use `defer` where this is already possible and ping your compiler vendor for those that do not have it yet. If there is enough demand, `defer` may even happen for the next standard release.
That may be true in your bubble, but I don't think this is true in general. There are still a lot C compilers out there, compared to 3 or 4 that do C++.
Thanks for the pointer! Definitively, on the long run these things should go into compilers directly, yes.
BTW, the break continue stuff now works in the development branch.
I notice that in that implementation there is an addition to the compiler state with indirections, whereas in ellipsis all is done with just three local variables; two per-function for knowing if we have to unwind completely and for the return value, and one per loop construct to know if we have to unwind there. All the rest is static information about nestedness and lexicographic ordering of code that can be deduced very early (here in the preprocessor). The result of all of this is a very organized braid of gotos, that in general are mostly optimized out.
This would be much more restrictive that what is proposed, because usually you would add `defer` statements as you go in a block, when you allocate more resources for example.
Also usually you should be able to have several actions,
defer {
one;
two;
}
And the bounding in the proposed feature is sane, I think, it is the surrounding compound statement (AKA `{ ... }` block).
That's not very practical if you have several operations to perform, you'd have to create a specialized function each time. So no, that extension is not an alternative to designing a new flow control feature. (And it is not new, other languages have it already.)
Besides C not having exceptions (that you could catch), the point was and is to have a way such that such a call has defined behaviour under any circumstances. The return value of the functions can even be ignored if the wrap around of the overflowing value is what your code expects.
So it is on the programmer to define what happens on error, they could ignore, try to back off by computing the high value bits, `exit` or `abort`.
Unfortunately there are several error conventions in the C standard.
Here, the committee just standardized existing practice, namely the gcc builtins. We just adjusted the call sequence in putting the pointer parameter for the result first.
In the current proposal, the whole function body can act as a guarded block. So for simple cleanup strategies that are bound to functions, you wouldn't need this.
No, actually none of that. That code has a constraint violation: it uses the variable i outside of its scope. Even if i would be declared on the same level as the guard, this sequence of deferred statements would not do good, but also not much harm. It would call foo with all the same value for i, namely n.
To have a good example where defer inside a loop actually does something, you'd have to capture the value of i. We also have a macro for that in the reference implementation, but that has a much more specialized scope of use.
That is effectively one of the options that is under discussion. One of the advantage of the approach with defer is really that everything happens in the open and all uses that one would want to classify as misuse can easily be flagged by the compiler.
In the contrary, I find it really weird to bind all cleanup code to some kind of object with constructors and destructors. People seem to have gotten so used to this ... I think that for C it is much more natural to have a control structure in the language for this.
In fact, the standard reflects what is happening in the field. So, use `defer` where this is already possible and ping your compiler vendor for those that do not have it yet. If there is enough demand, `defer` may even happen for the next standard release.