Re: Making a smart pointer which works with incomplete types
Alf P. Steinbach wrote:
In the face of complete code demonstrating that that isn't necessary,
you maintain that it's necessary.
Do you have some kind of difficulty in understanding the concept of
not changing the public interface of a class when its internal
implementation details change, and not adding additional requirements
for its use, when that is not necessary?
The fact is: A regular smart pointer which does not support incomplete
types can be changed into one which does, and this without modifying its
public interface and usage in any way whatsoever, and without adding any
requirements whatsoever for its usage.
You are heavily opposed to this, and instead would want to change the
usage of the smart pointer to be more complicated just because for
whatever reason I cannot fathom you abhor the idea of having a function
pointer stored somewhere (even though that's exactly what eg.
boost::shared_ptr does).
I'd give thanks if your solutions worked, but they don't.
Worked fine for me.
I'm at a loss as for how you have managed to make them not work.
You simply refuse to comprehend the concept of not adding additional
requirements for the user when that's not necessary in any way.
Of course your solutions "work". They work in the same way as using
just raw pointers and making the user call a deleter function manually
when he wants to delete the object. It indeed is possible to create a
perfectly working program that way.
Where that fails is in making the user's life easier rather than harder.
They just
make the usage of the class more complicated for no reason.
Also regarding the alleged complication.
Any additional requirement is useless complication.