Oh ok. The library does provide multiple ways to construct the objects in the array. So I don't think that's an issue.

See the test here: https://github.com/brenoguim/make_contiguous_objects/blob/a6a7024348450a72c77c5bd9857aa03aaa8894a0/tests/unit/basic.test.cpp#L91

I'm now in process of changing the implementation of libc++ shared_ptr to stress the API. Let's see how it goes.

By the way, the configurability of the initialization of each array is highly questionable because I haven't seen anything similar in the standard. So I might need to a more traditional approach?

I don't know, what do you think?

Thanks!

Breno G.

On Sun, Mar 12, 2023 at 4:05 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

On Sun, Mar 12, 2023 at 2:50 PM Breno Guimarães <brenorg@gmail.com> wrote:
> All our use-cases so far are use-cases for the allocating-but-not-constructing entrypoint.

Even on std::make_shared<std::string[]>(10) ? That is a case of allocating and constructing.

That default-constructs the 10 string objects, true. But it doesn't default-construct the 1 _ControlBlock object that precedes them:
https://github.com/llvm/llvm-project/blob/2f887c9a760dfdffa584ce84361912fe122ad79f/libcxx/include/__memory/shared_ptr.h#L1147-L1148
So an entrypoint that default-constructs all Ns... of the Ts... isn't helpful to this use-case.

–Arthur