Gosh, I'll have to rewrite a lot of the library to add _proper_ allocator
support. But the initial result is very encouraging.
Even though a few tests are still failing due to allocator support not
being 100%, I can see how the code will look like in the end.

My patch removes a wikipedia link explaining how to do proper padding, a
union that is only to simplify alignment, and the code is much more
readable.

I'll come back once it's ready.


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

> 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
>>
>>>