Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue822 below:

Object with explicit copy constructor no longer CopyConstructible

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

Section: 16.4.4.2 [utility.arg.requirements] Status: NAD Submitter: James Kanze Opened: 2008-04-01 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [utility.arg.requirements].

View all other issues in [utility.arg.requirements].

View all issues with NAD status.

Discussion:

I just noticed that the following program is legal in C++03, but is forbidden in the current draft:

#include <vector>
#include <iostream>

class Toto
{
public:
    Toto() {}
    explicit Toto( Toto const& ) {}
} ;

int
main()
{
    std::vector< Toto > v( 10 ) ;
    return 0 ;
}

Is this change intentional? (And if so, what is the justification? I wouldn't call such code good, but I don't see any reason to break it unless we get something else in return.)

[ San Francisco: ]

The subgroup that looked at this felt this was a good change, but it may already be handled by incoming concepts (we're not sure).

[ Post Summit: ]

Alisdair: Proposed resolution kinda funky as these tables no longer exist. Move from direct init to copy init. Clarify with Doug, recommends NAD.

Walter: Suggest NAD via introduction of concepts.

Recommend close as NAD.

[ 2009-07 Frankfurt: ]

Need to look at again without concepts.

[ 2009-07 Frankfurt: ]

Move to Ready with original proposed resolution.

[Howard: Original proposed resolution restored.]

[ 2010-11 Batavia: ]

This issue was re-reviewed in relation to [another issue, number to follow], and the verdict was reversed. Explicit copy and move constructors are rare beasts, and the ripple effect of this fix was far more difficult to contain than simply saying such types do not satisfy the MoveConstructible and CopyConstructible requirements.

In 16.4.4.2 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]:

expression post-condition T t (rv) = rv t is equivalent to the value of rv before the construction ...

In 16.4.4.2 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]:

expression post-condition T t (u) = u the value of u is unchanged and is equivalent to t ...

Proposed resolution:

Resolved by n3215.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4