Making a smart pointer which works with incomplete types

[Juha Nieminen]

And what is that price?

sizeof(T*) * amount_of_objects

 

[Juha Nieminen]

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).

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.

Also regarding the alleged complication.

Any additional requirement is useless complication.

 

[Juha Nieminen]

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.

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.

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.

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.

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.

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'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?"

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.

 

[James Kanze]

sizeof(T*) * amount_of_objects

Maybe, maybe not. On a Sun Sparc, in 32 bit mode, the price is
0. (Allocation granularity is 8 bytes, to ensure alignment of a
double. The reference count is 4 bytes. There are thus 4 bytes
leftover when it is allocated. Just the size of a T*.)

 

[Juha Nieminen]

Maybe, maybe not. On a Sun Sparc, in 32 bit mode, the price is
0. (Allocation granularity is 8 bytes, to ensure alignment of a
double. The reference count is 4 bytes. There are thus 4 bytes
leftover when it is allocated. Just the size of a T*.)

Question: Will shared_ptr in the new standard support user-defined
custom allocators for the smart pointer to allocate its data?

 

[James Kanze]

Question: Will shared_ptr in the new standard support
user-defined custom allocators for the smart pointer to
allocate its data?

I hope not. Too much added complexity for too little benefit.

 

[Kai-Uwe Bux]

I hope not. Too much added complexity for too little benefit.

The draft n2691 has an allocator for shared_ptr. Interestingly, I did not
find a get_allocator() function.


Best

Kai-Uwe Bux