I've started changing alot of my code now.
But I have a case where I use a unique_ptr as its a factory function that creates the object.. I then move this pointer into a owning container.. but I also have to set a currently selected object in another class.. should I rather use a shared_ptr in this case and use a weak_ptr for where I set the currently selected object? Or should I use a raw pointer for the selected object and get the raw pointer out of the unique pointer like I do below?
Raw pointer. If the object is deleted and then accessed by the currently selected pointer, that would usually indicate an error in your code and both weak_ptr and raw pointers will cause a runtime error here (assuming you don't check for a null shared_ptr from the weak_ptr's lock function). It's possible that a memory access to deleted memory will not cause a runtime error but this is rare and usually yields garbage data.
Using shared_ptr generally implies that there is shared ownership of the pointed-to object, so having only one shared_ptr to an object means that there is exclusive ownership, which makes the code less clear in addition to having more overhead. It's also possible that a second shared_ptr could be created by mistake which points to the same object, which is generally not desired (removing the object from the container should delete it) and not possible with the unique_ptr implementation.
Using shared_ptr for both the currently selected pointer and the container of objects would cause the object to remain in memory when the object is removed from the container while being referenced by the currently selected pointer, but this condition is usually errorneous (the selected pointer should generally only point to objects in the container), so this will mask the error and make it hard to detect.
The object may require shared ownership without considering the existance of the currently selected pointer (for example, if the object is immutable then you might want to copy a pointer to it instead of doing a full copy, in which case shared_ptr is appropriate). In this case, weak_ptr should be preferred since the overhead of having another weak_ptr instead of a raw pointer when the shared_ptr already exists is neglegible and the weak_ptr is more likely to detect errors. However, checking if the shared_ptr returned by weak_ptr's lock function is null should usually be omitted since it is usually a non-recoverable error to have the weak_ptr return a null shared_ptr.