On 18/03/2023 15.53, Breno Guimarães wrote:
> 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.

Good, so we've identified an elementary building block that is provably
useful for your library and for others. Let's go with that.

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

Ok, that's a different use-case, I think: Allocate, then run construction X,
then construction Y, and roll back if an exception happens.

This is what implicitly happens for a new-expression and class member construction,
but prior discussion in this thread has shown that the initialization doesn't
usually happen all at once for the multi-object case. This needs documented
use-cases.

> It would be like giving malloc but not class constructor.

malloc has existed for two decades or so before class constructors arrived.

> 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 <https://github.com/llvm/llvm-project/compare/main...brenoguim:llvm-project:breno.mco2>

Usage experience for a new facility is always welcome.

Jens


> 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] <mailto: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
>