A common style that I've seen is const-references for in-params (which should act like pass-by-value, but are expensive to copy) and pointers for all out params.
The rationale behind this is that it makes out-params very obvious at the call-site, similarly where in other languages the caller must use an 'out' keyword.
That would completely kill C++ as being a pay-for-what-you-use / opt-in language. Most embedded systems that I've worked on still use raw-pointers, or a smart pointer that acts like a raw one, but only performs leak detection during development.
It'd be nice if the syntax were a little cleaner in C++, but then it'd also be nice if owning pointers (std::unique_ptr) were a built-in feature like in Rust. C++ is not for people afraid of typing or syntax spew.
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?
I suppose if I need to share a dynamic resource to things outside of the raw pointer containing class then smart pointers become essential. 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. How then is the problem of detecting resource leaks handled? Is there a method to the madness or are designs/tools up to the task?
If there's any doubt, these are genuine questions and not quibbles with the concept of smart pointers. I just haven't been on a large enough project to see what disasters might befall the unwary.