I quite dislike the defer syntax. IMO the cleanup attribute is the much nicer method of dealing with RAII in C.
If you can't compile K&R, you should label your language "I can't believe it's not C!".
I don't have time to learn your esolang.
81–90 of 262 posts
I quite dislike the defer syntax. IMO the cleanup attribute is the much nicer method of dealing with RAII in C.
If you can't compile K&R, you should label your language "I can't believe it's not C!".
I don't have time to learn your esolang.
Can somebody explain why this is significantly better than using goto pattern? Genuinely curious as I only have a small amount of experience with c and found goto to be ok so far
The advantage is that it automatically adds the cleanup code to all exit paths, so you can not forget it for some. Whether this is really that helpful is unclear to me. When we looked at defer originally for C, Robert Seacord hat a list of examples and how the looked before and after rewriting with defer. At that point I lost interest in this feature, because the new code wasn't generally better in my opinion. But pe…
http://robertseacord.com/wp/2020/09/10/adding-a-defer-mechan...
Can somebody explain why this is significantly better than using goto pattern? Genuinely curious as I only have a small amount of experience with c and found goto to be ok so far
1. Goto pattern is very error-prone. It works until it doesn't and you have a memory leak. The way I solved this issue in my code was a macro that takes a function and creates an object that has said function in its destructor. 2. Defer is mostly useful for C++ code that needs to interact with C API because these two are fundamentally different. C API usually exposes functions "create_something" and "destroy_somethin…
For example if I have a ffi function that transfers the ownership of some allocator in the middle of the function.
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.
Probably closer to defer in Zig than in Go, I would imagine. Defer in Go executes when the function deferred within returns; defer in Zig executes when the scope deferred within exits.
In Golang if you iterate over a thousand files and
defer File.close()
your OS will run out of file descriptorsEarlier quoted context omitted.
Just straight up huffing paint are we.
Explain why? Have you used C99 designated init vs other languages? E.g. neither Rust, Zig nor C++20 can do this: https://github.com/floooh/sokol-samples/blob/51f5a694f614253... Odin gets really close but can't chain initializers (which is ok though): https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c11...
As far as I can tell, Rust can do what it is in your example (which different syntax of course) except for this particular way of initializing an array.
To me, that seems like a pretty minor syntax issue to that could be added to Rust if there would be a lot of demand for initializing arrays this way.
Earlier quoted context omitted.
Never, you can already do this with RAII, and naturally it would be yet another thing to complain about C++ adding features. Then again, if someone is willing to push it through WG21 no matter what, maybe.
C++ implementations of defer are either really ugly thanks to using lambdas and explicitly named variables which only exist to have scoped object, or they depend on macros which need to have either a long manually namespaced name or you risk stepping on the toes of a library. I had to rename my defer macro from DEFER to MYPOROGRAM_DEFER in a project due to a macro collision. C++ would be a nicer language with native…
Working with native C APIs in C++ is akin to using unsafe in Rust, C#, Swift..., it should be wrapped in type safe functions or classes/structs, never used directly outside implementation code.
If folks actually followed this more often, there would be so much less CVE reports in C++ code caused by calling into C.
Earlier quoted context omitted.
> I still stay with C89 because I know it will be portable anywhere With respect, that sounds a bit nuts. It's been 37 years since C89; unless you're targeting computers that still have floppy drives, why give up on so many convenience features? Binary prefixes (0b), #embed, defined-width integer types, more flexibility with placing labels, static_assert for compile-time sanity checks, inline functions, declarations…
To be honest I have similar reservations. The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002. (That's a rare enough situation to be unimportant, right? /laughs in industrial control gear.) I'm wary of anything which fragments the language and makes it inaccessible to sub…
Earlier quoted context omitted.
C++ implementations of defer are either really ugly thanks to using lambdas and explicitly named variables which only exist to have scoped object, or they depend on macros which need to have either a long manually namespaced name or you risk stepping on the toes of a library. I had to rename my defer macro from DEFER to MYPOROGRAM_DEFER in a project due to a macro collision. C++ would be a nicer language with native…
Because they are all the consequence of holding it wrong, avoiding RAII solutions. Working with native C APIs in C++ is akin to using unsafe in Rust, C#, Swift..., it should be wrapped in type safe functions or classes/structs, never used directly outside implementation code. If folks actually followed this more often, there would be so much less CVE reports in C++ code caused by calling into C.
If I'm constructing a particular C object once in my entire code base, calling a couple functions on it, then freeing it, I'm not much more likely to get it right in the RAII wrapper than in the one place in my code base I do it manually. At least if I have tools like defer to help me.
Earlier quoted context omitted.
The advantage is that it automatically adds the cleanup code to all exit paths, so you can not forget it for some. Whether this is really that helpful is unclear to me. When we looked at defer originally for C, Robert Seacord hat a list of examples and how the looked before and after rewriting with defer. At that point I lost interest in this feature, because the new code wasn't generally better in my opinion. But pe…
Thanks, seems like the document is this one http://robertseacord.com/wp/2020/09/10/adding-a-defer-mechan...