C++ Logo

std-proposals

Advanced search

[std-proposals] Generalizing std::uninitialized_fill

From: Giuseppe D'Angelo <giuseppe.dangelo_at_[hidden]>
Date: Sat, 13 Jul 2024 13:51:16 +0200
Hi,

I was wondering if a variadic uninitialized_* algorithm has ever been
proposed. std::uninitialized_fill, "despite" its name,
direct-non-list-initializes each object in the range using its input
argument:

https://eel.is/c++draft/uninitialized.fill

The T parameter can be anything, as it's deduced. In particular, it
doesn't have to be the range's value type (resulting in copies). From
this point of view, it looks more like a form of emplacement, with some
limitations: precisely one argument, and can't invoke a constructor that
takes by non-const reference due to the parameter being a const ref.


So I was wondering if a generalization of fill has ever been proposed?


Something like:

> template<class NoThrowForwardIterator, class... Args>
> /* constexpr */ void uninitialized_construct(NoThrowForwardIterator first, NoThrowForwardIterator last, Args&&... args);

Effects:

> for (; first != last; ++first)
> ::new (voidify(*first))
> typename iterator_traits<NoThrowForwardIterator>::value_type(args...); // forward deliberately missing


Example:

> std::string *storage = allocate(3); // allocates storage for 3 strings
> std::uninitialized_construct(storage, storage+3, 100, 'x'); // builds 3 strings, each containing 100 'x'


Note the difference with:

> std::uninitialized_fill(storage, storage+3, std::string(100, 'x'));

which builds *4* strings (1 temporary in the caller, and 3 copy
constructed from it, into the algorithm.)


Also note that, in general, fill/construct don't require copiability
from the range's value type.



Is this emplacement? Almost: we can't perfectly forward the arguments as
we're building N objects. (In principle we could forward them to the
very last object built, but I am not sure I like that N-1 objects get
built in one way and 1 in a different way.)

One can also imagine a uninitialized_list_construct algorithm that uses
direct list initialization.

Opinions?


(Also: since P2747 this can be constexpr. P2283R2 proposed to mark the
other uninitialized_* algorithms as such, but I'm not sure what happened
to that paper? Is it sitting on LWG's plate? Does it need a sponsor?)


Thank you,
--
Giuseppe D'Angelo

Received on 2024-07-13 11:51:20