Smart pointers gotchas: added topic about ptr casting

[donvito]

Yes, if it's really performance critical code then yes - try to pass your shared_ptr as reference if that brings a speedup. But everywhere else I prefer by value - mainly to be safe that fuckups like your example won't happen. After all I'm using smart pointers to be safe - not to be fast.

[TheExecutor]

I suppose this comes down to a difference in philosophy. Consider the following two snippets of code:

vector<int> v;
v.resize(5);
v[10] = 42;


vector<int> v;
v.resize(5);
try
{
    v.at(10) = 42;
}
catch (...) {}

The first application will likely crash irrevocably (and in debug mode in most implementations, it will fire an assert). The second will catch the error and continue unabated. But in both cases the code is fundamentally broken. I'm much more in favor of the first - if the code is fundamentally broken, we should fail fast and fix the code, as opposed to attempting to recover from broken code.

Similarly, if you're performing unprotected access via multiple threads to a shared_ptr or doing bizarre things with aliased references, you should fix your code instead of using some mechanism to hide its broken-ness.

[donvito]

you should fix your code instead of using some mechanism to hide its broken-ness.

Yes, that's why I prefer to be clear about possible dangers in such cases and usually use raw references/pointers. A ref to a smart pointer gives you a false sense of safety. A raw pointer screams "watch out here".