From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-30 18:37:01
> > (a) no operator->() or operator*() (or any other smart_ptr specific
> > functions there may happen to be)
> > (b) an emphasis on open/ close semantics
> > (c) a discreet name and concept for resource ownership semantics.
> > Admittedly point (c) and, to a certain extent, point (b) could at least
> > partly mitigated by the presence of the fabled template typedefs,
> > think it would ignore, in the process, the perspective that led to both
> > these points in the first place).
> This is really funny. To me, on the contrary, (a) is a moot point, and (b)
> and especially (c) are important.
Well I'm glad there was some entertainment value at least ;-)
Personally I don't consider (a) a moot point (at least not in the sense of
it not being worthy of discussion).
> To clear a possible confusion, if nobody calls operator-> or operator* for
> smart_ptr, they won't be generated at all, even though their generation
> would yield a compiler error. So they're just sitting there harmlessly.
I was not confused about that. But I don't see them as being "harmless". I
might stretch to "mostly harmless" :-)
But to me, the fact that they are there - in the explicit interface of the
object you have in your hand - just doesn't ring right. However I am
prepared to accept that that opinion is not shared by the heavyweight
contributors here. I am obviously in a minority here and will bow to the
community view (for now ;->).
> I do agree that, as Sven also noted, smart_ptr makes it possible, but not
> particularly comfortable, to accomodate various types of resources.
Well, at least I got that token agreement :-)
To me it just "smells bad".
> A good approach to a smart resource would be a carefully designed class
> based on policies. Ideally, some policies would agree with smart_ptr's
> policies that represent the same concepts. Internally, that smart resource
> could use smart_ptr as an implementation device. Or is it the other way
> around? :o)
Ok, I'll bite - it's the other way round! Or even, as I suggested
previously, have a top level RaiiHolder which could be broken down into
smart_resource and smart_ptr.
But I'm running out of arguments (I have more if I think hard enough, but I
don't think they say much I haven't already said).
I think it a shame because I think people will probably not use what could
be quite a powerful feature just because it is hidden away...
(btw, I think it's great that your design does cater for use as smart
resources, and this is certainly better than none at all).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk