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_at_[hidden]>
wrote:

> On Sun, Mar 12, 2023 at 2:50 PM Breno Guimarães <brenorg_at_[hidden]> 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
>
>>