3 ms·
>I also have some ideas how to make this defer implementation work with break and continue, but that is unfortunately a bit more nasty. This is the kind of thi
by fuhsnn 2y ago
>I also have some ideas how to make this defer implementation work with break and continue, but that is unfortunately a bit more nasty.
This is the kind of things better done in the compiler, I implemented the n3199 variant of defer[1], along with [[gnu::cleanup]], in a small C compiler with about 200 LOC by extending the VLA de-allocation algorithm, the process is archived at [2].
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm
[2] https://github.com/fuhsnn/slimcc-defer/commits/ https://github.com/fuhsnn/slimcc-defer/commits/
- gustedt 2y agoThanks 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.