Date: Sun, 12 Mar 2023 12:17:40 -0400
On Sun, Mar 12, 2023 at 11:02 AM Breno GuimarĂ£es via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi folks,
>
> A while ago I floated the idea of having a function to allocate contiguous arrays of objects.
>
> I didn't have anything concrete to show back then, so I'm coming back with a bit more meat to the idea:
> https://github.com/brenoguim/make_contiguous_objects/blob/main/README.md
>
> I'm looking for feedback on more use cases, maybe discussing alternative APIs, and arguments against having this in the standard.
>
> The last time I got feedback to apply it in major codebases (listed in the motivation section), and I'll get to it now that I'm back to work on this.
>
> Thanks!
> Breno G.
I really don't like the interface, receiving a tuple of spans which
you then have to delete by sending this tuple to some other function.
Thus far, all of the `make_*` functions work via RAII: the object you
get back either itself is the memory or is managed by a RAII object
like `unique_ptr`. Either way, the object returned owns any storage
associated with it.
I feel like this should be the case for your `make_*` function too.
You can have a `std::get`-based interface to retrieve spans if you
like, but it should not be a bare tuple that you then have to manage.
There can be an alternate version for allocating such arrays in
existing storage, but the `make` version should use RAII management.
<std-proposals_at_[hidden]> wrote:
>
> Hi folks,
>
> A while ago I floated the idea of having a function to allocate contiguous arrays of objects.
>
> I didn't have anything concrete to show back then, so I'm coming back with a bit more meat to the idea:
> https://github.com/brenoguim/make_contiguous_objects/blob/main/README.md
>
> I'm looking for feedback on more use cases, maybe discussing alternative APIs, and arguments against having this in the standard.
>
> The last time I got feedback to apply it in major codebases (listed in the motivation section), and I'll get to it now that I'm back to work on this.
>
> Thanks!
> Breno G.
I really don't like the interface, receiving a tuple of spans which
you then have to delete by sending this tuple to some other function.
Thus far, all of the `make_*` functions work via RAII: the object you
get back either itself is the memory or is managed by a RAII object
like `unique_ptr`. Either way, the object returned owns any storage
associated with it.
I feel like this should be the case for your `make_*` function too.
You can have a `std::get`-based interface to retrieve spans if you
like, but it should not be a bare tuple that you then have to manage.
There can be an alternate version for allocating such arrays in
existing storage, but the `make` version should use RAII management.
Received on 2023-03-12 16:18:52