Allocgate: Restructuring how allocators work in Zig

Re:Allocgate: Restructuring how allocators work in Zig by jcelerier on Wednesday December 15, 2021 @04:31PM (#29571890)

> There is a lack of standardized RAII wrappers for handle types like there is for pointers.

.. what's wrong with

    #include <memory>

    template<typename T, auto Free>
    using safe_handle_t = std::unique_ptr<T, decltype([] (auto p) { Free(p); })>;

    using file_handle = safe_handle_t<FILE, fclose>;

    void file_example() {
        file_handle f{fopen("foo", "r")};
    }

[ Parent | on HN ]

Re:Allocgate: Restructuring how allocators work in Zig by spacechild1 on Wednesday December 15, 2021 @07:22PM (#29573303)

That's what I do as well. Many people are not aware that std::unique_ptr can do more than just manage heap memory.

[ Parent | on HN ]

Re:Allocgate: Restructuring how allocators work in Zig by 10000truths on Wednesday December 15, 2021 @04:54PM (#29572085)

Now you have a double indirection. Worse, the handle probably already references dynamically allocated memory. So that’s two dynamic memory allocations per “safe” handle. Which might be perfectly acceptable for non-critical programs, but it is certainly going to tank your memory usage efficiency and thrash your CPU cache if scaled up to millions of handles.

[ Parent | on HN ]

Re:Allocgate: Restructuring how allocators work in Zig by jcelerier on Wednesday December 15, 2021 @06:02PM (#29572678)

This is entirely wrong. This produces exactly the same code than

    auto f = fopen("foo", "r");
    if(f)
      fclose(f);

check for yourself: https://gcc.godbolt.org/z/YxaPqYGez

[ Parent | on HN ]

Re:Allocgate: Restructuring how allocators work in Zig by fbkr on Wednesday December 15, 2021 @05:49PM (#29572578)

There is no double indirection and allocation here, it stores the FILE* directly, not as a pointer to a FILE*.

[ Parent | on HN ]