|
Boost : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-02 15:19:03
----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> > 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).
Until the last reference to the COM object which was copied from a
single shared_ptr disappears, you just decrement the (boost) shared
count. You only make an indirect function call when that count goes to
zero. This could be a significant savings in many situations. Imagine
insertions into a vector of shared_ptr to COM objects.
> 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.
Why is it dangerous? I think "unsynchronized" can be a very good thing
when you're not copying shared_ptrs across thread boundaries. This is in
the realm of "don't pay for what you don't use".
> > 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.
Something is missing above?
> > 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.
For the record, I'm with Andrei on this one. At least, the 2nd statement
seems completely wrong to me.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk