I don't work on large projects - just my own small game project, so take this with a grain of salt.
Is a valid use of raw pointers for things within a class? For example, if I construct an object (and correctly release resources if the object fails to construct) and then provide the correct release in the destructor would this be a valid use? I guess that's the RAII paradigm in a nutshell. Or would you advocate smart pointers even in this scenario?
The thing is, std::unique_ptr wraps all that for you. It's not just a matter of a destructor - you also need copy operators, assignment operators, move operators, and move-assignment operators.
std::unique_ptr has zero overhead in size and de-reference speed as a normal pointer (when compiler optimizations are properly turned on).
std::unique_ptr doesn't permit copying - so you'd still have to implement a copy-constructor and do an explicit copy, but you'd've had to do that anyway.
There are some situations where new
should still be used, but those are few and far between.
Raw pointers are also fine when they don't *own* the memory, and when the lifetime of the memory is guaranteed to outlast the raw pointer. So raw pointers shouldn't be *rare*, just less common than previously.
I suppose if I need to share a dynamic resource to things outside of the raw pointer containing class then smart pointers become essential.
Depends what you mean by 'share'. Just return a reference (usually const) if you mean 'shared access'. If you mean 'shared ownership' of the memory, then yes, std::shared_ptrs are a likely choice - but it'd depend on the situation. If you want to share access, but you aren't sure if the memory will outlast the pointer/reference, than std::shared_ptr for the owner(s), and std::weak_ptrs for the accessor(s).
But even general purpose libraries intended for mass consumption avoid smart pointers because there's no hard bound guarantee that the same smart point convention is followed by programs which use different implementations.
I'm not exactly sure what you mean here. Are you saying, different implementations of custom
smart pointer classes, or are you saying different implementations of standard library smart pointers?
If the former, the solution is to use standard library pointers. If the latter, the solution is that you should be building those third-party libs from source code anyway, because who knows what compiler settings they used, and all your code should be compiled with the same compiler settings regardless of whether smart pointers were used.