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
>> >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
>(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
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.
>Just for the record, I completely disagree with the argument and comparison
>> 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
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk