From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-19 05:04:54
From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > >
> > > I understand. And the constness of intrusive_ptr_add_ref ultimately
> > relies on the constness of the count object, when there is one. If
> > are valid reasons to have the const object be either const or non-const,
> > suppose the choice sould be passed up to the user.
> > The choice _is_ left to the user. :-)
> Yes, technically it is, but not in a convenient fashion, since he would
need to create his own mutable counted_base. Hence your smile, I presume.
I think that <T const> support is quite important, and so counted_base
should have its count mutable (with associated changes to free functions),
This comes at a cost. counted_base::release() const implies
counted_base::dispose() const. The function that dispose() performs is to
release any resources managed by the object. Hence, these resources would
need to be made mutable, and const correctness goes MIA.
> or there should be two counted_base-style classes provided.
Possible, but not strictly necessary. counted_base is provided since it is
an important bridge between intrusive_ptr and shared_ptr; if it weren't
provided, the user wouldn't be able to define it.
The "other" counted_base can be defined by the user, since there is nothing
special about it. It would be convenient to have it, of course, if there is
demand for a standard counted base with const addref/release methods.
> What's your plan for gathering enough information to make a decision on
how to proceed?
My "highly scientific" plan is:
1. Replace all of my intrusively counted pointers with
boost::intrusive_ptr<>. See if any problems surface (none so far; I've no
need of intrusive_ptr<T const>.)
2. Wait for feedback from intrusive_ptr users (if there are any.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk