temporary-objects

Prerequisities: To understand this question, please, read the following question and its answer at first: Cast auto_ptr<Base> to auto_ptr<Derived> At Cast auto_ptr<Base> to auto_ptr<Derived> Steve answered that "Your static_cast would copy the auto_ptr to a temporary, and so aS would be reset and the resource would be destroyed when the temporary is (at the end of the statement)." I'm interested in the process of temporary creation while static_cast is called. I would like to have the code that I can trace in order to see this effect. I cannot use static_cast<auto_ptr<Circle>> ... because it

#include <iostream> using namespace std; struct CL { CL() { cout<<"CL()"<<endl; } CL(const CL&) { cout<<"CL(const CL&)"<<endl; } ~CL() { cout<<"~CL()"<<endl; } }; CL cl; CL fnc() { return cl; } int main() { cout<<"start"<<endl; const CL& ref=static_cast<const CL&>(fnc()); //...Is "ref" valid here?? cout<<"end"<<endl; return 0; } What's lifetime of temporary object returned by fnc()? Is it lifetime of "ref" or of temporary reference static_cast(fnc()), which destroyed at end of statement? Output of gcc (lifetime of fnc() is lifetime of "ref"): CL() //global object "cl" start CL(const CL&) end

Given the following code, where x is a dangling const reference to a vanished object, and is therefore undefined behavior. auto get_vec() { return std::vector<int>{1,2,3,4,5}; } const auto& x = get_vec().back(); It seems like neither GCC 7.3 , Clang 6.0 and MSVC is able to emit a warning, even with all warnings enabled. Does anyone know if it is any way to emit a warning in these cases? Is there any difference between const auto& and auto&& in these cases? Note, if back() would return by value, it wouldn't be undefined behavior as the lifetime temporary object x is extended to function scoop.

I'm using Visual Studio Express 2013 and is fooling around a bit trying to learn about different things in C++. I stumbled upon an interesting bug in the compiler where it doesn't seem to create a temporary object when explicitly type casting to the same type as the reference. #include <iostream> using namespace std; int main() { int number; // float number; number = 2; const int& plainref_i = number; const int& recastref_i = (int)number; // this goes wrong if number is int const float& plainref_f = number; const float& recastref_f = (float)number; // this goes wrong if number is float number

A regular string string literal has the following definition: Ordinary string literals and UTF-8 string literals are also referred to as narrow string literals. A narrow string literal has type “array of n const char”, where n is the size of the string as defined below, and has static storage duration (3.7). I'm assuming because it has static storage duration and that they're typically placed in ROM, it really isn't a big deal if there's a dangling reference to it. The following code emits a warning const char* const & foo() { return "Hello"; } // warning: returning reference to temporary [

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

Consider the following code: #include <iostream> using namespace std; class A { public: int a; A(): a(5) { cout << "Constructor\n"; } A(const A &b) { a = b.a; cout << "Copy Constructor\n"; } A fun(A a) { return a; } }; int main() { A a, c; A b = a.fun(c); return 0; } The output of the above code with g++ file.cpp is: Constructor Constructor Copy Constructor Copy Constructor The output of the above code with g++ -fno-elide-constructors file.cpp is: Constructor Constructor Copy Constructor Copy Constructor Copy Constructor I know Return Value Optimization. My question is which call to copy

I'm aware of the fact that assigning an rvalue to a const lvalue reference extends the temporaries lifetime until the end of the scope. However, it is not clear to me when to use this and when to rely on the return value optimization. LargeObject lofactory( ... ) { // construct a LargeObject in a way that is OK for RVO/NRVO } int main() { const LargeObject& mylo1 = lofactory( ... ); // using const& LargeObject mylo2 = lofactory( ... ); // same as above because of RVO/NRVO ? } According to Scot Meyers' More Effective C++ (Item 20) the second method could be optimized by the compiler to