Never ever use a raw pointer when a smart pointer can do the same job

[Noah Roberts]

[...about enforcing heap allocated objects...]

Actually, I'm going to expand this...not for your benefit, but for
anyone confused by your disagreement with something I never stated.

A self deleting object is one that will respond to some function calls
by calling "delete this". Example:

struct self_deleter { void do_something() { delete this; }};

The fact that it will do this requires that this object always be
created by a call to new. Note that there is no way for the object to
know how it was created unless it enforces that method so it can't
conditionally delete based on how it was created.

The above class is badly design because it can be used incorrectly. Your
class advertises an interface that is inappropriate for its use: namely
it can be created on the stack as a local variable. Any such use though
will evoke serious derangement in the program which will most likely
exhibit itself by a hard crash...as in the program just disappears on
the user.

It seems you didn't understand why Alf made the destructor protected. It
serves two purposes:

1) You cannot call 'delete that' on a pointer to this object, so you
enforce the 'delete this' policity.
2) You cannot allocate that object on the stack, because it would
require a call to the destructor, which is protected.

So Alf's solution does everything you want, but avoids factory
functions. By this way, you can use all constructors of the class
normally, and you don't need to provide one factory function for every
constructor of that class.

The factory function and protection of stack protection discussions are
two completely different sub-topics with different disagreements.

If people just read threads, and paid attention to context of individual
messages rather than merging them from across discussion, it would make
discussions a lot less tedious.