+3  A: 

So to protect against this problem you can make your contstructors private and only provide creation functions that return shared_ptr - this way the object can't be allocated on the stack, like this:

class C : public enable_shared_from_this<C>
{
public:
  static shared_ptr<C> create() { return shared_ptr<C>(new C() ); }
  shared_ptr<C> method() { shared_from_this(); }

private:
  C() {...}

  // Make operator= and C(const C&) private unimplemented
  // so the used cant do bad things like C c( * c_ptr );
  C& operator=( const C & );
  C( const C & );
};


void func()
{
  C c; // This doesnt compile
  shared_ptr<C> ptr = c.method(); // So you can never get this
}

void altfunc()
{
  shared_ptr<C> c_ptr = C::create();
  C & c_ref = *c;
  shared_ptr<C>  ptr = c_ref.method(); // OK
}

If you find yourself wishing for anoperator= you can provide a clone function using a private implemented copy constructor, something like this

// This goes in class C
shared_ptr<C> C::clone() const
{
  return shared_ptr<C>( new C(*this) );
}

// This is how you can use it
shared_ptr<C> c2 = c1->clone();
Michael Anderson
I'm aware that you can probably still allocate these on the stack if you're willing to jump through some hoops to be intentionally evil.. but IMHO this protects from most innocent mistakes.
Michael Anderson
So we will initially design heap-only classes... Is this approach are widely used ?
vnm