should std::common_type use std::decay? Yes, see Library Working Group Defect #2141. Short version (long version, see link above): declval<A>() returns a A&& common_type is specified via declval, n3337: template <class T, class U> struct common_type<T, U> { typedef decltype(true ? declval<T>() : declval<U>()) type; }; common_type<int, int>::type therefore yields int&&, which is unexpected proposed resolution … Read more
Even after fixing all other problems to make the code compile, it only works in VC2010 because it uses a non-standard extension. And If you specify /Wall to see all warnings, you compiler will emit warning C4213: nonstandard extension used : cast on l-value
A compound literal is an lvalue and values of its elements are modifiable. In case of char* str = (char[]){“Hello World”}; *str=”B”; // A-Okay! you are modifying a compound literal which is legal. C11-ยง6.5.2.5/4: If the type name specifies an array of unknown size, the size is determined by the initializer list as specified in … Read more
Most of the work is already done for you by the stdlib, you just need a function wrapper: template <typename T> constexpr bool is_lvalue(T&&) { return std::is_lvalue_reference<T>{}; } in the case you pass a std::string lvalue then T will deduce to std::string& or const std::string&, for rvalues it will deduce to std::string Note that Yakk’s … Read more
&std::string(“Hello World”) The problem with this isn’t that std::string(“Hello World”) yields a temporary object. The problem is that the expression std::string(“Hello World”) is an rvalue expression that refers to a temporary object. You cannot take the address of an rvalue because not all rvalues have addresses (and not all rvalues are objects). Consider the following: … Read more
should that work in c++11? No, it should not. Foo is a custom class, I don’t understand why the first two line compiles It compiles only with MSVC. MSVC has an (arguably useful) compiler extension that allows binding lvalues of user-defined types to rvalues, but the Standard itself forbids this. See, for instance, this live … Read more
The standard correctly defines the return type of an assignment operator. Actually, the assignment operation itself doesn’t depend on the return value – that’s why the return type isn’t straightforward to understanding. The return type is important for chaining operations. Consider the following construction: a = b = c;. This should be equal to a … Read more
An even better example, unary + yields an rvalue, as does x+0. The underlying reason is that all these things, including your cast, create a new value. Casting a value to the type it already is, likewise creates a new value, never mind whether pointers to different types have the same representation or not. In … Read more
This is one of the most common “rules of thumb” used to explain what is the difference between lvalues and rvalues. The situation in C++ is much more complex than that so this can’t be nothing but a rule of thumb. I’ll try to resume a couple of concepts and try to make it clear … Read more
string literals are lvalues, but you can’t change them rvalue, but if it’s a pointer and non-NULL, the object it points to is an lvalue The C standard recognizes the original terms stood for left and right as in L = R; however, it says to think of lvalue as locator value, which roughly means … Read more