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