101–110 of 262 posts
Earlier quoted context omitted.
I was under the wrong assumption that defer was approved for the next standard already.
We will likely decide in March that it will became an ISO TS. Given the simplicity of the feature and its popularity, I would assume that it will become part of the standard eventually.
Earlier quoted context omitted.
I do not see how defer would have helped in this case.
People manually doing resource cleanup by using goto. I'm assuming that using defer would have prevented the gotos in the first case, and the bug.
Using defer, the code would be:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
return err;
return err;
Earlier quoted context omitted.
This certainly isn't RAII—the term is quite literal, Resource Acquisition Is Initialization, rather than calling code as the scope exits. This is the latter of course, not the former.
People often say that "RAII" is kind of a misnomer; the real power of RAII is deterministic destruction. And I agree with this sentiment; resource acquisition is the boring part of RAII, deterministic destruction is where the utility comes from. In that sense, there's a clear analogy between RAII and defer. But yeah, RAII can only provide deterministic destruction because resource acquisition is initialization. As lo…
Which removes half the value of RAII as I see it—needing when and to know how to unacquire the resource is half the battle, a burden that using RAII removes.
Of course, calling code as the scope exits is still useful. It just seems silly to call it any form of RAII.
Earlier quoted context omitted.
I wonder what the thought process of the Go designers was when coming up with that approach. Function scope is rarely what a user needs, has major pitfalls, and is more complex to implement in the compiler (need to append to an unbounded list).
I hate that you can't call defer in a loop. I hate even more that you can call defer in a loop, and it will appear to work, as long as the loop has relatively few iterations, and is just silently massively wasteful.
But there are lots of cases in the kernel where we have 10+ goto labels for error paths in complex setup functions. I think when this starts making its way into those areas it will really start having an impact on bugs.
Sure, most of those bugs are low impact (it's rare that an attacker can trigger the broken error paths) but still, this is basically free software quality, it would be silly to leave it on the table.
And then there's the ACTUAL motivation: it makes the code look nicer.
Earlier quoted context omitted.
I do not see how defer would have helped in this case.
People manually doing resource cleanup by using goto. I'm assuming that using defer would have prevented the gotos in the first case, and the bug.
Earlier quoted context omitted.
I hate that you can't call defer in a loop. I hate even more that you can call defer in a loop, and it will appear to work, as long as the loop has relatively few iterations, and is just silently massively wasteful.
The go way of dealing with it is wrapping the block with your defers in a lambda. Looks weird at first, but you can get used to it.
The article is a bit dense, but what it's announcing is effectively golang's `defer` (with extra braces) or a limited form of C++'s RAII (with much less boilerplate). Both RAII and `defer` have proven to be highly useful in real-world code. This seems like a good addition to the C language that I hope makes it into the standard.
I’m just going to start teaching classes of C programming to university first-year CS students. Would you teach `defer` straight away to manage allocated memory?
If you're teaching them to write an assembler, then it may be worth teaching them C, as a fairly basic language with a straightforward/naive mapping to assembly. But for basically any other context in which you'd be teaching first-year CS students a language, C is not an ideal language to learn as a beginner. Teaching C to first-year CS students just for the heck of it is like teaching medieval alchemy to first-year…
Earlier quoted context omitted.
I do not see how defer would have helped in this case.
People manually doing resource cleanup by using goto. I'm assuming that using defer would have prevented the gotos in the first case, and the bug.
C is hard enough as is to get right and every tool and development pattern that helps avoid common pitfalls is welcome.