Zig, Skia, Clojure, Geometry and the Japanese TV Show: ICFP Contest 2021

Re:Zig, Skia, Clojure, Geometry and the Japanese TV Show: IC... by Arnavion on Thursday July 15, 2021 @07:30PM (#27851316)

>This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that.

This is missing the point. The point of a destructor is that it runs automatically. .deinit() is the same as the three cleanup_*()s in my example and thus has the same problems.

>but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront

The third example in my post shows why this is inadequate.

[ Parent | on HN ]

Re:Zig, Skia, Clojure, Geometry and the Japanese TV Show: IC... by dnautics on Thursday July 15, 2021 @09:26PM (#27852129)

Then im not really sure what your point is, because I've written zig code that reuses code in a similar way to what you are talking about, with three different forms of parallelism calling into some common runner code each of which has different needs for resource cleanup times (single threaded, cooperative, and independent parallelism). It wasn't a problem.

Have you tried doing what you propose in zig? Ultimately, the only difference between a .deinit() and a destructor is that one is explicit and the other is not. There are cases where you can easily make a mistake for both an explicit destructor and an implicit destructor.

[ Parent | on HN ]