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.

A few ideas:
- new_contiguous_objects
- new_adjacent_objects
- new_arrays
- new_objects
- all above with "create_*" instead

>My "minor" nitpick — which is highly relevant to Jason's point — is that
your first section *should not use `auto s`*.

I avoided that in the initial example to highlight the "creation" part,
instead of the management. I talk about the return value later on. But I
agree the reader it might leave the reader confused.

Best Regards,
Breno G.


On Sun, Mar 12, 2023 at 1:26 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Mar 12, 2023 at 12:18 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sun, Mar 12, 2023 at 11:02 AM Breno Guimarães via Std-Proposals wrote:
>> >
>> > 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.
>>
>> 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.
>>
>
> I haven't read the proposal in depth yet, but it sounds like I'd agree
> with Jason.
> My "minor" nitpick — which is highly relevant to Jason's point — is that
> your first section *should not use `auto s`*.
>
> auto s = std::make_contiguous_objects<char, int, long>(numC, numI, numL);
>
> You need to spell out the type here, so that the reader can see what
> you're proposing.
> If your answer truly is
> std::tuple<std::span<char>, std::span<int>, std::span<long>> s =
> std::make_contiguous_objects<char, int, long>(numC, numI, numL);
> then you've got a big problem with resource management and you need to
> keep iterating on it.
>
> FWIW, consider a signature of the form
>
> template<class... Ts>
> auto make_shared_contiguous_objects(decltype(void_t<Ts>(), size_t())...
> counts)
> -> std::tuple<std::shared_ptr<void>, Ts*...>;
>
> and then see if you can find a way to analogize that for unique ownership.
> (The caller already knows the lengths of all the spans, so you shouldn't
> be repeating that back to them unless the ergonomics are overwhelmingly in
> its favor.)
>
> my $.02,
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>