> There are too many APIs that still want raw pointers.

Irrelevant. C++'s smart pointers deal with ownership and life cycle management. You can still pass raw pointers to objects managed by a smart pointers.

The only exception is when you're dealing with a framework which already handles life cycle management, such as Qt. Nevertheless, even Qt offers its own smart pointers suite.

> You can still pass raw pointers to objects managed by a smart pointers.

Not if the API is taking ownership and you want your program to be correct. This happens far more often than dealing with something like Qt.

If the API takes ownership, can't you just release the smart pointer, effectively forgetting about it and letting the new owner deal with it? Maybe I'm missing somethign.

That means it is no longer managed by a smart pointer and you need to understand the nature of the API. I understood the above comment to mean that you can just solve problems by calling "get" and moving on with your life.

There's nothing wrong with using a raw pointer as an argument of a function. In this context this is usually equivalent to using a reference. What is wrong, in fact, is passing, instead, a unique pointer (by reference, necessarily) or, even worse, a shared pointer (by value) when there is no need for sharing.

> In this context this is usually equivalent to using a reference.

Not really. The very, very, very important difference is that the pointer can be null, signalling "no object". For some purposes, this is a critically important difference; in other cases, you should be passing a reference.

Even if they want to take ownership, smart pointers allow the semantics to be expressed clearly and in a safe manner.