Re: Making a smart pointer which works with incomplete types
Alf P. Steinbach wrote:
Your whole point was that storing this pointer anywhere could be
avoided altogether.
Demonstrated now two or three times
By making the usage of the smart pointer more complicated.
Why not forget the whole smart pointer and use raw pointers instead?
Then it certainly is not necessary to store *any* additional data.
Oh, it's more complicated that way? But that's not important. What's
important is that no function pointers are stored anywhere.
So an additional requirement of "if you instantiate the smart pointer
in an environment where the type is complete, include this file, else
include this another file" is not error-prone?
Well it isn't like that. It's not an either-or for the includes. And you
don't actually need to include anything for the instantiation.
Wow, now you are able to instantiate your smart pointer without even
declaring it? That's cool.
Having to choose between different header files depending on whether
the type might be incomplete or not.
You have misunderstood. There is no choice of header files. There's just
a choice of where to get a definition from: write it (1 line) or
#include it (1 line), which anyway makes that part very explicit, which
is good.
It makes the usage inconsistent, adding additional choices for the
user to make, which is bad. Not only bad, but unnecessary.
That's not the simplest thing to do. The simplest thing is when you
*don't have to* tell the compiler about your special cases and instead
the compiler can deduce them itself automatically.
If you're not aware that you're dealing with incomplete type then
something is very wrong.
Now it's you who is babbling.
Do you understand the concept of abstraction? The more abstract your
program is, the better. When you *don't have to know* how things are
implemented, the better.
We are talking about complexity from the point of view of the user, in
other words, the complexity of the public interface of the class and its
requirements, ie. how complicated it is to use.
How complicated the private implementation of a class is, is
completely inconsequential as long as it causes the public interface to
be easy to use and safe, and preferably the class as efficient as
possible.
Yeah, except none of that is relevant.
It might not be relevant to you, but for people who want to keep their
classes as simple and easy to use as possible, it is.
From the computer's point of view one function pointer per used type
is nothing. It doesn't even require any significant amounts of memory.
Thus the implementation is very efficient with respect to memory
consumption.
You've argued the opposite earlier in this thread.
Where exactly? Please point me to the specific post. I dare you.
My original post was *precisely* about saving memory by using a static
function pointer rather than a non-static one. The non-static member
pointer consumes memory for each object instance, while a static one
doesn't. It only consumes memory for each used type, thus potentially
saving enormous amounts of memory.
Perhaps you have reading comprehension problems?
I didn't agree then
Agreed about what? You are not even making any sense anymore.
I have trouble grasping why you're arguing for that pointer, given that
your question was how to get rid of it.
Where did you get this impression? I never said I want to get rid of
it. What I said is that I want to take it out of the smart pointer
object so that it doesn't increase its size.
"I'm more worried about the space that pointer requires.
Making it static removes it from the smart pointer object, making the
smart pointer smaller and lighter. It seems to me that it's perfectly
possible to create a smart pointer class which works with incomplete
types without any overhead"
And yes, it's possible, and you've been shown how.
Maybe you should read that quote again?
I said there: "If you make the function pointer static, it removes the
overhead from the smart pointer".
Do you understand what my actual question was? And no, it was not "how
do I get rid of this pointer completely?"
This goal can be achieved by making the user create such a function
and giving it to the smart pointer. No matter how many tricks you try to
invent to automatize this as much as possible, it will always require
the user to explicitly write something extra. This is needlessly
burdensome and error-prone. It's needlessly so because it can be easily
avoided.
Another way of achieving this is by the smart pointer automatically
instantiating the deleter function itself. The only place where it can
do so (as per the specs) is in the constructor. After this the only way
the destructor can call this automatically generated function without
actually instantiating it itself as well, is through a function pointer.
There's no way of passing this function pointer from the constructor to
the destructor other than storing it somewhere.
You've been given complete code that demonstrates that conclusion to be
false.
A complete code which requires the user to write additional code to
create the deleter function. Unnecessarily.