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