[boost] Re: [boost] Re: [boost] Curaçao: reaction to smart pointer proposal

From: Greg Colvin (greg_at_[hidden])
Date: 2002-04-30 16:31:20

At 02:08 PM 04/30/2002, you wrote:
>At 02:53 PM 4/30/2002, Greg Colvin wrote:
>
>>At 12:41 PM 04/28/2002, Beman wrote:
>>
>>>* LWG members are very concerned that "you don't have to pay for what you
>>don't use." This is particularly true of memory; increased memory use due
>>to multiple inheritance or to accommodate weak_ptr, for example, is viewed
>>as a serious problem.
>>
>>I don't really think that is such a big issue, unless shared objects
>>are hardly shared at all, and maybe not even then.
>>
>>The overhead for the weak pointer need be only one word per object, not
>>per pointer, and the smart pointer itself need be only one or two words.
>
>Well, the issue could be put to rest by providing sizeof() information for a number of compilers.  Test code should probably report sizeof() routinely, since it is something that people do care about.
>
>It isn't so much a concern for single smart pointers, but when you have a vector of smart pointers, sizeof() each smart pointer gets important.

Either I wasn't clear, or I misunderstand the LWG concerns.

All versions of boost::shared_ptr consist of two pointers -- one
to the shared object and one to the shared counter.  Two words on
most machines.  At the cost of an indirection that can be reduced
to one word, but last we looked at it we decided to go for speed
over space.  Standard library implementors are free to make the
best tradeoff for their platform.  This choice is independent of
whether to support weak pointers.

For each shared object the boost::shared_ptr allocates a counter,
consisting of a long and virtual destructor.  On most platforms
this will require two words: one for the counter and one for the
vtable pointer.  There are other ways to implement virtual
functions, but I'm not sure what their overhead is.

So for boost::shared_ptr we can estimate that the cost used to be
2 words per pointer plus 1 word per object, and now it is 2 words
per pointer plus 3 words per object.  Clearly, the more objects
are shared per object, and the bigger the shared objects, the less
difference that extra two words makes to the overhead.  So, for
example, if you have 100 byte objects, and average 10 pointers per
object, the overhead for supporting weak pointer is only .001 words
per pointer, i.e. 1 tenth of 1 percent.

So the question is, what is the distribution of the numbers of
shared_ptr per object?  And what is the distribution of the size of
objects?  And how much overhead is too much?  My take is that the
question of whether to support weak_ptr by default in the standard
library comes down to how useful the feature is more than to how
much overhead is creates.

For boost, we have already made that choice, but recently enough
that we haven't gotten much feedback on whether the cost is OK.