Boost logo

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
> > 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
> 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
> 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
> above.

For the record, I'm with Andrei on this one. At least, the 2nd statement
seems completely wrong to me.


Boost list run by bdawes at, gregod at, cpdaniel at, john at