Ownership and reference counting issues? The last thing you want is for
the smart pointer to delete the object while something else still holds
a pointer to it.
That was one of the few things that I had thought of. But, requiring
a get() method does little to help with that. Aren't you always just
going to call get() and use dumb ptr as you would have if it were
implicitly converted? To think that this will somehow alleviate the
programmer from reasoning about such things is quite naive (and in
fact, it could be argued that it gives novice programmers a false
sense of security). You still have to be careful with what you do
with a ptr that you obtain through get() as well as one implicitly
converted.
One of the main reasons for using a smart pointer type is to manage the
lifetime of a object.
I've always avoided implicit conversions from smart pointers. Requiring
one is a design smell
I suppose our senses of smell are subjective then. :-) I don't think
that C++, the language, was ever designed to prevent programmers from
doing stupid things (and boost is definitely breaking with the
tradition of C++ on this one). If 'safety' is what you want, you
might be using the wrong language. Any type of casting operator
overload is going to be 'unsafe' by this definition (not just those
relating to smart ptrs).
I've thought quite a bit about this and the only somewhat reasonable
situation I could see it being an issue is when converting a large
project over from dumb ptrs to smart ptrs (and missing one of the
conversions). But, if you are writing code from scratch, why wouldn't
you just use the smart ptrs everywhere? Performance impact is
minimal. If you get a situation where you really need to optimize for
performance, then isolate the bottleneck and write in assembly or C.
If you are careful enough to think about using dumb ptrs here for perf
reasons or smart ptrs there for convenience, then you should be
careful enough to be 'safe' doing it.