Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-02 10:53:35


"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:133a01c1f1c7$00b96320$6401a8c0_at_boostconsulting.com...
> [...]
> 2. It does mean that the constructors/destructors of empty policies get
> skipped (compressed_pair doesn't have that issue, but has others)

If the default policies are any indication, this shouldn't be a problem.

> 3. Is using public inheritance at all really important? My impression
> is that you do this to allow the policies to add interface to the
> smart_ptr... while at the same time you eschew public member
> functions.

Well, *I* eschewed public member functions. ;) The original Loki
code has public members all over. ;)

> The tack taken by the iterator_adaptors library is to expose all
> possible interface in the outer template (in this case smart_ptr),
> and generate compiler errors inside those functions in case of
> illegal usage. The only way that could break down would be in
> case defining these outer level functions changed overload
> resolution somehow, but I'm under the impression that for the
> types of interface you're defining in smart_ptr, that can't happen
> (?)

Hmm. That's possible. I did have to struggle a bit with operator[],
and at one point, had an outer-level version forwarding to the
policy; but it all seemed to just work when I took out the outer
level forwarder. I don't know if that's because of overload rules,
or just my incompetence. ;) It seems pretty easy to get the
compiler confused between picking operator[] and the operator
tester*. On the other hand, I do like the ability to add interface
at the policy level. This might be more important with the smart
resource usage, if people want to forward a lot of resource
functions from a policy. I'm still thinking about making a serial-
izable policy that lets you store an ID in the pointer, and I'd
hate to clutter the top-level interface with this small corner case.
What do you think?

Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk