If your Zig code has a for loop in a deinit method, you're using computers wrong.
If your C++ destructor is doing O(N) work thanks to RAII, you are using C++ correctly, but you are still using computers wrong.
8
Replies
0
Boosts
@andrewrk sorry I am a bit of a newbie in programming. What about having multiple objects in the gpu ? Is there anything possible for OpenGL or Vulkan for example ?
@andrewrk
Andrew Kelley nagging me to finally intern my strings......
@andrewrk RAII is optional in C++, zig doesn't even give you the option. And as others have posted in the thread, not every resource fits nicely in an arena world view.
@andrewrk I spent a few minutes grepping and skimming Zig's standard library, and there are so many cases with O(n) deinit that you must be trolling. There's a useful and valid version of your heuristic statement. E.g. a single munmap in the wrong place can be a huge problem, and that's a case where the O(n) loop is in the kernel and the constant factor is excellent (inversely proportional to the page size).
@pervognsen not trolling! There is plenty of room to improve Zig standard library along this axis. Did you find any interesting examples where the generalization does not apply?
@andrewrk I'm not sure what generalization you mean, but I think the subject is too broad and context-specific to make a general true statement along these lines. Let's focus on deinit vs other kinds of work. Agreed that with Zig-style explicit deinit but even more so with implicit deinit, there's a tendency for people to downplay or ignore the negative impact of deinit work, despite the fact that it almost always involves paying off debts incurred earlier.
@andrewrk I don't get it: an array of file handles, or VkImage has to ne freed sequentially. If the API has array version of these it's nice to use them, but sometimes they just don't exists.
@andrewrk What do you recommend instead?
