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




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

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!


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