Re: [boost] Re: Traits-based design and ODR

From: Greg Colvin (greg_at_[hidden])
Date: 2002-05-02 16:35:18

At 01:54 PM 05/02/2002, you wrote:
>"Greg Colvin" <greg_at_[hidden]> wrote in message
>news:5.1.0.14.0.20020502104307.02ad0560_at_GMMAIL...
>> >1. Shared pointers allow you to change at runtime the function with
>> >which the pointer is destroyed.
>>
>> For shared_ptr, at construction time.
>
>This is an irrelevant distinction:
>
>shared_ptr<FILE> sp1(someHandle, fclose);
>...
>sp1 = shared_ptr<FILE>(sp1.get(), my_fclose);

Yes, you could compile this, but it would be very wrong, even
without the change of close functions.

I consider it unfortunate that we expose the shared_ptr
constructor from raw pointer and the pointer itself to the
user, but there are language and historical reasons for that
choice.

>(I'm not sure how shared_ptr<FILE>s are copied. I assume in this case they
>call a system function to duplicate the handle.)

No.  You can just copy FILE*.  Standard C does not expose the
Unix dup() functionality.

And, referring back to a point you made about HANDLE causing
shared_ptr<HANDLE> to different things (like files and windows)
to be assignable, I think the real problem is that Win32 uses
a void* handle to point to all kinds if things, and has many
functions that work on generic HANDLEs, as well as many functions
that work only on specific HANDLEs.  It's a mess to untangle,
but can be done with a wrapper class for the generic HANDLE and
derived classes for more specific HANDLEs.

> In my experience, the fastest way to handle COM locally is to do AddRef
>> once when constructing a shared_ptr, and Release once when counter
>> goes to zero, and save the virtual function calls.
>
>You don't save nothing in the case of shared_ptr because you release through
>indirect function calls, which cost exactly as much as virtual calls (in COM
>at least).

You call IUnknown::Release only when the local shared_ptr count goes to
zero.  So if you make a enough copies you win by avoiding lots of AddRef
and Release calls.

>In my experience, the best way to deal with COM pointers is to use their own
>mechanism - call AddRef and Release and not use two redundant,
>unsynchronized, dangerous means of reference counting.

What I propose is not redundant, and is save.

>> I think copying is much more frequent than destruction.
>
>destruction because you need to decrement the reference count of the old
>object and check if it went to zero.
>
>> >4. shared_ptr is a point in smart_ptr's design space.
>>
>> It could be, yes.  And vice versa.
>
>I have a hard time understanding how the subset can be a superset of the set
>to which it belongs.
>
>For starters, how can I build a shared_ptr that's four bytes large?
>
>> The beauty of Loki is that it IS a framework, and offers much
>> power and convenience to those find it an appropriate framework.
>>
>> But the Standard Library, traditionally, is not so much a
>> framework as a collection of utilities.
>[snip]
>
>Just for the record, I completely disagree with the argument and comparison
>above.
>
>> Another bastion is years of experience with shared_ptr, which
>> indicates that it is "good enough" for most purposes, that it
>> can be tweaked over time to handle other important purposes,
>> and can provide hooks for user extension in unanticipated
>> ways.
>
>What can then be said about my and my colleagues' experience with several
>refinements of Loki's smart pointer?
>
>> The syntax is easy for the most common case, easy
>> enough for anticipated extensions, and well within the skill
>> of those who would design new extentions.
>
>As I said: syntax /is/ the last bastion :o).

Resistance is futile.  But honorable.

So get some sleep (it really is non-optional, unless you can get
a modafinil prescription) and read my reply to Gennadiy, which answers
more of your points.

Then we can negotiate shared_ptr's assimilation.