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

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

At 04:46 PM 04/30/2002, you wrote:
>"Greg Colvin" <greg_at_[hidden]> wrote in message
>news:5.1.0.14.0.20020430142655.02e70d20_at_GMMAIL...
>> 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.
>
>I argue that this is not the case for smart pointers. A smart pointer can be
>designed so that it gets rid of the extra storage except when needed, and
>does not lose in the abstraction domain at all. Therefore, why not using the
>better design, if efficiency also comes as a fringe benefit of it?

Because for a small (e.g. one tenth of one percent) cost in space
we get a shared_ptr that can assigned to weak_ptr.  For Boost I
think it's worth it, but what the LWG, and then the full committee
will think I don't know.  I can also imagine designs that have no
overhead for weak_ptr until one is created -- for instance, put
the weak counts in a map, at some cost in speed once the map is
non-empty.

Can we leave all these decisions to the user?

Of course we can.

What does that cost the user?

Binary compatibility.  If two libraries use a semantically
identical smart pointer, but the implementation is different,
then their smart pointers may not be binary compatible with
each other.  And the two libraries may even be two different
versions of the same library.