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@gmail.com> 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@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:
So an entrypoint that default-constructs all Ns... of the Ts... isn't helpful to this use-case.

–Arthur