prvalue | 易学教程

Lifetime extension, prvalues and xvalues

阅读更多关于 Lifetime extension, prvalues and xvalues

问题 Following the well accepted answer to this question Do rvalue references allow dangling references? It would seem that xvalues do not have their lifetime extended when assigned to a rvalue reference lvalue like in the question. However when I do this #include <iostream> using namespace std; class Something { public: Something() { cout << "Something()" << endl; } Something(const Something&) { cout << "Something(const Something&)" << endl; } Something(Something&&) { cout << "Something(Something

Cv-qualifications of prvalues (revisited)

阅读更多关于 Cv-qualifications of prvalues (revisited)

问题 This is a followup to my previous question, where the apparent consensus was that the change in treatment of cv-qualifications of prvalues was just a fairly minor and inconsequential change intended to solve some inconsistencies (e.g. functions returning prvalues and declared with cv-qualified return types). However, I see another place in the standard that appears to rely on prvalues having cv-qualified types: initialization of const references with prvalues through temporary materialization

How do we test if an expression of a certain type can be invoked with a prvalue?

阅读更多关于 How do we test if an expression of a certain type can be invoked with a prvalue?

问题 With c++17 we have fancy new is_invocable and fancy new prvalues that aren't really values. This permits you to create an object without having to first logically construct it, then elide the construction. I have run into a problem where using std::is_invocable to test if you can call something, and prvalue rules, seem to collide: struct no_move { no_move(no_move&&)=delete; explicit no_move(int) {} }; void f( no_move ) {} now can we ask if f can be invoked using a prvalue of type no_move ? f(

Cv-qualifications of prvalues (revisited)

阅读更多关于 Cv-qualifications of prvalues (revisited)

This is a followup to my previous question , where the apparent consensus was that the change in treatment of cv-qualifications of prvalues was just a fairly minor and inconsequential change intended to solve some inconsistencies (e.g. functions returning prvalues and declared with cv-qualified return types). However, I see another place in the standard that appears to rely on prvalues having cv-qualified types: initialization of const references with prvalues through temporary materialization conversion . The relevant wording can be found in multiple spots in 9.3.3/5 [...] If the converted