Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.

724.DefaultConstructible is not defined

Section: 16.4.4.2[utility.arg.requirements]Status:C++11Submitter: Pablo HalpernOpened: 2007-09-12Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [utility.arg.requirements].

View all issues withC++11 status.

Discussion:

TheDefaultConstructible requirement is referenced inseveral places in the August 2007 working draftN2369,but is not defined anywhere.

[Bellevue:]

Walking into the default/value-initialization mess...

Why two lines? Because we need both expressions to be valid.

AJM not sure what the phrase "default constructed" means. This isunfortunate, as the phrase is already used 24 times in the library!

Example:const int would not accept first line, but will accept the second.

This is an issue that must be solved by concepts, but we might need to solve it independantly first.

It seems that the requirements are the syntax in the proposed firstcolumn is valid, but not clear what semantics we need.

A table where there is no post-condition seems odd, but appears to sum up our position best.

At a minimum an object is declared and is destructible.

Move to open, as no-one happy to produce wording on the fly.

[2009-07-28 Reopened by Alisdair. No longer solved by concepts.]

[2009-08-17 Daniel adds "[defaultconstructible]" to table title.408⁽ⁱ⁾depends upon this issue.]

[2009-08-18 Alisdair adds:]

Looking at the proposed table in this issue, it really needs two rows:

Table 33:DefaultConstructible requirements [defaultconstructible]

expression	post-condition
T t;	t is default-initialized.
T{}	Object of typeT is value-initialized.

Note I am using the new brace-initialization syntax that is unambiguousin all use cases (no most vexing parse.)

[2009-10-03 Daniel adds:]

The suggested definitionT{} describing it asvalue-initialization is wrong, because it belongs to list-initializationwhich would - as the current rules are - always prefer ainitializer-list constructor over a default-constructor. I don'tconsider this as an appropriate definition ofDefaultConstructible. My primary suggestion is to ask core,whether the special caseT{} (which also easily leads toambiguity situations for more than one initializer-list in a class)would always prefer a default-constructor - if any - before consideringan initializer-list constructor or to provide another syntax form toprefer value-initialization over list-initialization. If that fails Iwould fall back to suggest to use the expressionT() instead ofT{} with all it's disadvantages for the meaning of theexpression

T t();

[2009-10 Santa Cruz:]

Leave Open. Core is looking to make Alisdair's proposedresolution correct.

[2010-01-24 At Alisdair's request, moved his proposal into the proposed wordingsection. The old wording is preserved here:]

In section 16.4.4.2[utility.arg.requirements], before table 33, add thefollowing table:

Table 33:DefaultConstructible requirements [defaultconstructible]

expression	post-condition
T t; T()	T isdefault constructed.

[2010-02-04: Moved to Tentatively Ready after 5 positive votes on c++std-lib.]

Rationale:

[San Francisco:]

We believe concepts will solve this problem(N2774).

[Rationale is obsolete.]

Proposed resolution:

In section 16.4.4.2[utility.arg.requirements], before table 33, add thefollowing table:

Table 33:DefaultConstructible requirements [defaultconstructible]

expression	post-condition
T t;	Objectt is default-initialized.
T u{};	Objectu is value-initialized.
T() T{}	A temporary object of typeT is value-initialized.