Ggtcf

Short and simple question:

I am aware that in a move constructor / overloaded assignment you must set RValue references that refer to pointers to nullptr (at the end) in order to avoid deallocation of that resource.

For the same reason, I assume RValue references delete their bound (non-pointer) object after it is assigned to another pointer, meaning the behaviour of the pointer is undefined after. (I'm not sure if this is true)

My question is will a similar code snippet to the following have defined behaviour (if I were to use pNum)? :

//Foo.h
class Foo 
 public:
 Foo(int &&num);
 private:
 int *pNum;
;

//Foo.cpp
Foo::Foo(int &&num)
:pNum(&num)//Would using/dereferencing pNum in the future cause defined behaviour? 

If this is an incorrect method of optimising functions through the use of RValue references as parameters, what is the correct method? e.g. What methods do std functions like emplace or make_shared use?

I am aware that in a move constructor / overloaded assignment you must set RValue references that refer to pointers to nullptr (at the end) in order to avoid deallocation of that resource.

You don't. It's a common pattern, but it's not fundamental to how move semantics work. What you need to do, is set things up such that the destruction of the moved-from object won't mess up the moved-to object. In the case of pointers which the destructor is going to free, setting them to nullptr is the obvious choice, but having a separate bool m_hasBeenMovedFrom member set to true would also work, as would setting the pointer to point to a newly allocated object.

The important thing, though, is that rvalue references themselves don't do anything like that. Rvalue references are just a variant of references with slightly different binding semantics from lvalue references. They don't delete things any more than lvalue references do.

In the code you posted, the constructor is receiving an rvalue reference to an object, and storing a pointer to that object. That's dangerous, because you could do something like Foo f(3) (or, since it's a non-explicit one-argument constructor, even just pass 3 to a function expecting a Foo), which would store the pointer to an expiring value. On the other hand, if the passed-in object was guaranteed to outlive Foo everything would be okay, but if you're requiring that, why use an rvalue reference?

Overall, while the code you showed there doesn't by itself have undefined behavior, it is absolutely begging for UB to happen when the class is used. The connotation of an rvalue reference is "this object will be gone soon, so feel free to steal its belongings". An int doesn't have any belongings, so that's not useful... and since it's about to be gone, you don't want to hold a pointer to it.

Incidentally, you will often see standard library functions (and other functions!) of the form template<typename T> someFunc(T && arg). That is not an rvalue reference, but a "forwarding reference", aka a "universal reference", which scads of pages will tell you about (but this is my favorite one). The main thing to remember here is that T && is only going to act like an rvalue reference if it's given an rvalue, and that the function itself needs to be careful not to unconditionally treat it as an rvalue reference.