Hi Jens,

I meant that I had to rewrite most of my library.

Having a function to return uninitialized arrays is definitely a
possibility. It even already exists inside my library implementation.

The drawback is that initializing multiple arrays is tricky enough that I
wanted to provide that functionality as well.

If any constructor in any array throws, you have to destroy all objects in
that array (easy, uninitialized_* functions give you that) but also the
objects in other arrays you already created and finally release the buffer.
It would be like giving malloc but not class constructor.

But perhaps my best chance of getting anything approved will giving up on
something. The 'args' API is indeed too non fitting.

I wrote a version of your suggestion applied to simplify the libc++ shared
ptr. It also looks pretty clean:
https://github.com/llvm/llvm-project/compare/main...brenoguim:llvm-project:breno.mco2

Maybe that is indeed the way to go.


Thanks!
Breno G.

On Sat, Mar 18, 2023 at 6:26 AM Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> On 13/03/2023 00.34, Breno Guimarães via Std-Proposals wrote:
> > Gosh, I'll have to rewrite a lot of the library to add _proper_
> allocator support.
>
> What do you mean? Does libc++ not correctly interact with the allocator?
>
> General remark on the proposal: It seems it delivers useful functionality
> for the case "allocate memory for these arrays, with proper alignment".
> Having that in a non-RAII wrapper as the lowest-level interface seems
> plausible (there are no destructors to call at that level), and
> allocator-style functions don't give you RAII, in general.
>
> This also removes all the std::arg business from the interface surface.
>
> Would an interface like
>
> template<class ... Ts>
> std::tuple<Ts * ...> allocate_arrays( decltype(std::void_t<Ts>,
> std::size_t>)... );
>
> help most of the use-cases? If someone wants construction,
> the std::uninitialized_* algorithms are at their service.
>
> (The std::uninitialized_* algorithms seem to deal in pointers-to-T
> even when pointing to not-yet-constructed memory.)
>
> Jens
>