Thread: Temporary object return

This would be more of a real world example:

Code:

#include "stdafx.h"
#include <iostream>
#include <utility>
#include <ctime>
#include <cstdlib>

class A
{
public:
	A(int n) 
	{
		std::cout << "A: Constructing...\n";
		m_n = n;
		m_p = new int[1000];
	}
	A(A& rhs)
	{
		std::cout << "A: Copy constructing...\n";
		m_p = new int[1000];
		std::copy(rhs.m_p, rhs.m_p + 1000, m_p);
		m_n = rhs.m_n;
	}
	A(A&& rhs)
	{
		std::cout << "A: Move constructing...\n";
		m_p = rhs.m_p;
		rhs.m_p = nullptr;
		m_n = rhs.m_n;
	}
	~A() 
	{
		std::cout << "A: Destructing...\n";
		delete [] m_p;
	}

	int m_n;
	int* m_p;
};

A&& foo()
{
	static A test(std::rand());
	return std::move(test);
}

A bar()
{
	A test(std::rand());
	return test;
}

int main()
{
	std::srand(std::time(nullptr));

	{
		std::cout << "Test with foo:\n";
		A tmp = foo();
		std::cout << "Result: " << tmp.m_n << std::endl;
	}
	{
		std::cout << "\nTest with bar:\n";
		A tmp = bar();
		std::cout << "Result: " << tmp.m_n << std::endl;
	}
	{
		std::cout << "\nTest with foo (r-ref):\n";
		A&& tmp = foo();
		std::cout << "Result: " << tmp.m_n << std::endl;
	}
	{
		std::cout << "\nTest with bar (r-ref):\n";
		A&& tmp = bar();
		std::cout << "Result: " << tmp.m_n << std::endl;
	}
}

Constructors now do something useful.
(Although if this isn't optimized out by the compiler isn't certain; yet it is only there for demonstration and has no real point, so that's fine.)

Thank you very much for all your posts, 19 posts in such a short time. I am not too sure what happened with my code when I was testing it for the supposed "incorrect case" as laserlight pointed out. I was getting a NULL object as a result for one of my tests, but I probably did some simple mistake like using "Str&" as the return type. Laserlight also mentioned the possibility of using the "<<" operator, which I commonly use, but am a little confused on how to implement such an overload without editing the Str library's file.

But what also seems interesting is the copy and move constructors. I have never run across those before, but they seem pretty interesting. I am assuming that each class have a built in default mover/copier? Or am I mistaken? The only way I did copying in the past was to overload the operator= to do my own little copying method.

Thanks again for all the great support.

Code:

A&& foo()
{
	static A test(std::rand());
	return std::move(test);
}

This function is also horribly broken.

1) If your test program shows two different values from foo, that's because your constructors don't initialize the data members. Foo always returns A with the same random value, unlike bar.

2) It also says that the function is done with the instance `test` and is happy if you decide to move from it (i.e leaving it in an unspecified state). Which means that only the first invocation may have a meaningful result.

E.g, if the result is used like this:

Code:

A a = foo();

then it invokes the move constructor which is free to invalidate the right-hand object (foo::test).

Code:

A& foo()
{
	static A test(std::rand());
	return test;
}

This should be the correct way (except that rand is called just once). The inclusion of rvalue references doesn't mean that normal references suddenly stop doing their job.

Nor does it mean that you should abuse rvalue references for performance, sacrificing code correctness.

Originally Posted by jakebird451

But what also seems interesting is the copy and move constructors. I have never run across those before, but they seem pretty interesting. I am assuming that each class have a built in default mover/copier? Or am I mistaken? The only way I did copying in the past was to overload the operator= to do my own little copying method.

All classes have a default copy constructor. No move constructor, however, AFAIK (how can the compiler know how to properly move resources?).

If I'm not mistaken, you get default move constructors under certain conditions: no user-defined copy constructor + no user-defined destructor + all members are movable, or something like that. (This has been rather volatile in the drafts, I think.)