C++ Logo


Advanced search

Re: [std-proposals] Making contiguous objects

From: Jens Maurer <jens.maurer_at_[hidden]>
Date: Sat, 18 Mar 2023 23:35:38 +0100
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

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


> 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

Received on 2023-03-18 22:35:42