On Sun, Mar 12, 2023 at 12:58 PM Breno Guimarães <brenorg_at_[hidden]> wrote:

> Hey folks,
>
> Thanks for your inputs.
> I think I might need another name then. I agree that "make" will give the
> impression of something that is properly managed.
>
> There are two reasons for avoiding RAII at this point:
> 1. As described here
> https://github.com/brenoguim/make_contiguous_objects/blob/main/README.md#implicit-memory-layout
> I don't expect users to actually store the return type very often because
> it has redundant information. The whole point is to have something that is
> suitable for container internals.
> 2. RAII can be later built on top of the raw facility.
>

It's much easier to call `.release()` on a properly managed RAII
return object, than it is to remember to call `delete[]` (or whatever) on a
non-RAII return value.
In fact, I think I see that your current proposal proposes a free function
`destroy_contiguous_objects<Ts...>`? That smells like a destructor. So why
not just do something like `node_handle`?

template<class... Ts>
struct contiguous_storage_manager {
    ~contiguous_storage_manager(); // correctly frees the allocation e.g.
by calling delete [] (std::byte*)p_;
private:
    void *p_; // exposition only
};
template<class... Ts>
std::tuple<contiguous_storage_manager<Ts...>, Ts*...>
make_contiguous_storage(decltype((Ts*)nullptr, size_t())... counts);

And now I'm confused: Is this make_contiguous_*objects* or make_contiguous_
*storage*? Because most library users will need the latter, not the former.
If you construct objects, then you need the manager to remember how many of
each type of object to destroy (not just the total number of bytes, which
the C++ runtime remembers for us for free anyway).

–Arthur