Boost logo

Boost :

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-28 18:55:45

It seems the the smart_ptr thread has gone quiet just recently. Is that just
because Andrei has been busy with other things, or did we come to some final

I have a couple of things to bring to the discussion. The one I will talk
about here I have mentioned before but I'm not sure my concern was
addressed. I will raise my other point in another mail as it is orthagonal
(and I need to give it more thought anyway).

When I brought up the matter of a smart_resource before it was pointed out
to me that Loki::SmartPtr already caters to such a need. But my real concern
at the time was that, while smart_resource and smart_ptr certainly have a
lot in common (and could be implemented one in terms of the other, although
it would seem a mistake to implement smart_resource in terms of smart_ptr),
they are sufficiently different entities to deserve first class seperation
of identity. This I believe, directly impacts the complexity of the
interaction between policies (not vastly, but enough).
More importantly they are, IMHO, solving similar, yet subtly different
semantic issues. I know this is open to interpretation but it does strike me
as a symptom of over design.
I think this has been brushed under the carpet a lot, but following the
dialog mostly between Andrei and Gennadiy the issue came up several times
where the smart_resource aspects of smart_ptr had been overlooked, or there
was an awkward naming issue depending on whether we were dealing with
pointers or general resources.

I am prepared to accept that I am alone in having reservations about using
smart_ptr to manage non-pointer resources (as opposed to having a discreet
smart_resource class), and if everyone else is happy with this I will bring
it up no more. However, nobody has, AFAICS explicity said this yet.

FWIW, my view of a separate smart_resource does not preclude the sharing of
individual existing smart_ptr _policies_, where appropriate.



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