Allocator-awareness and value-initialization on container elements

[Ai Azuma]

Hi, folks.

I found that the word "value-initialized" is used in the Effects
paragraph of the following constructors and member functions;

explicit deque::deque(size_type n);
void deque::resize(size_type sz);
explicit forward_list::forward_list(size_type n);
forward_list::resize(size_type sz);
explicit list::list(size_type n);
void list::resize(size_type sz);
explicit vector::vector(size_type n);
void vector::resize(size_type sz);

Here, I interpret the meaning of "value-initialization" as defined in
(8.5).

However, as far as I understand correctly, the actual semantics should
be emplace construction from zero argument,
i.e., `std::allocator_traits<allocator_type>::construct(a, p)', where
a is a value of the allocator type and
p is a pointer to the place at which a new element is constructed.
This expression may not value-initialize the element but invoke a
constructor other than the default one.
For example, consider the case where the allocator type is
`std::scoped_allocator_adaptor'.

Therefore, the word "value-initialized" should not be used in these
Effects paragraphs.
In addition, the wording like "EmplaceConstructible from zero
argument" should be used
in the corresponding Requires paragraphs instead of
"DefaultConstructible."

I would like to hear from experts. Thank you in advance for your help.


--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Daniel Krügler]

Am 30.09.2011 19:36, schrieb Ai Azuma:
> Hi, folks.
>
> I found that the word "value-initialized" is used in the Effects
> paragraph of the following constructors and member functions;
>
> explicit deque::deque(size_type n);
> void deque::resize(size_type sz);
> explicit forward_list::forward_list(size_type n);
> forward_list::resize(size_type sz);
> explicit list::list(size_type n);
> void list::resize(size_type sz);
> explicit vector::vector(size_type n);
> void vector::resize(size_type sz);
>
> Here, I interpret the meaning of "value-initialization" as defined in
> (8.5).

This is correct.

> However, as far as I understand correctly, the actual semantics should
> be emplace construction from zero argument,
> i.e., `std::allocator_traits<allocator_type>::construct(a, p)', where
> a is a value of the allocator type and
> p is a pointer to the place at which a new element is constructed.
> This expression may not value-initialize the element but invoke a
> constructor other than the default one.
> For example, consider the case where the allocator type is
> `std::scoped_allocator_adaptor'.
>
> Therefore, the word "value-initialized" should not be used in these
> Effects paragraphs.
> In addition, the wording like "EmplaceConstructible from zero
> argument" should be used
> in the corresponding Requires paragraphs instead of
> "DefaultConstructible."

I completely agree with what you write here. Note that there exists a
new proposal

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3301.pdf

which has basically the same effect, but introduces a separate new term
for allocator-aware containers - DefaultInsertable - which is defined to
be equal to

allocator_traits<A>::construct(m, p);

(Just ignore the 'contruct' typos in the paper). I consider the
introduction of a separate new name (but still easy to recognice with
the good ol' DefaultConstructible requirement set).

In regard to your criticism of the term value-initialization I agree as
well. IMO the proposal should be updated to fix these terms here as well.

HTH& Greetings from Bremen,

Daniel Krügler

[Ai Azuma]

On Oct 2, 12:12 am, Daniel Krügler<daniel.krueg...@googlemail.com>
wrote:

> I completely agree with what you write here. Note that there exists a
> new proposal
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3301.pdf
>
> which has basically the same effect, but introduces a separate new term
> for allocator-aware containers - DefaultInsertable - which is defined to
> be equal to
>
> allocator_traits<A>::construct(m, p);
>
> (Just ignore the 'contruct' typos in the paper). I consider the
> introduction of a separate new name (but still easy to recognice with
> the good ol' DefaultConstructible requirement set).

Oh, sorry. I overlooked that paper. Thank you for your kindness.

In essence, I am happy to see that the proposal agreed with me
that elements in containers should be consistently
constructed and destroyed via allocator traits' member functions.

> In regard to your criticism of the term value-initialization I agree as
> well. IMO the proposal should be updated to fix these terms here as well.

I hope the current wording will get fixed and become more precise.

Thank you for your reply!