Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 18:58:55

"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:

> "David B. Held" <dheld_at_[hidden]> wrote in message
> news:b19ic3$m48$1_at_main.gmane.org...
>> Indeed.  My new suggested change involves breaking orthogonality
>> in a way that I think even Beman suggested, if memory serves me
>> correctly.
>
> Ideally, SmartPtr should orchestrate the workings of the policies together
> while they are aloof of each other.
>
> In this particular case, if we are to apply this approach, it seems like
> SmartPtr should detect that the appropriate ownership policy fails to
> construct, and should say "never mind" to the storage policy by triggering
> its destruction. This sounds like a reasonable approach to me.
>
> It looks like SmartPtr cannot apply this simple algorithm due to syntactic
> and semantic issues of the language, which some (including me) deem as
> problems with the language.

It could do that; You'd just need to make room to handle in-place
construction and destruction itself (a technique I know you're
familiar with).  I'm not sure that's a language problem since after
all situations like this don't arise often and the workaround is
correspondingly difficult.

Hmm, you want these policies to be bases, though, so they can inject
interface, right?  Should a class really be allowed to control the
construction and destruction of its bases?  That sounds frought with
peril to me.  If you have a picture of how this would work, can you
describe it?

> So my suggestion is to work around the language instead of breaking
> orthogonality gratuitously.

I'd have suggested the same thing if I thought that breaking
orthogonality was gratuitous in this case, i.e. if there was a
workaround within the current language that didn't compromise
efficiency in a serious way.  Do you see a way to handle it?

> I believe this is NOT an example when orthogonality plays against
> you.

Orthogonality itself never plays agin' ya.  It's when you try to force
orthogonality on things which actually have to cooperate closely that
you get problems.  I'm not sure we have that case here, but it looks
like a possibility.  One way out, as Dave H. has suggested, might be
to impose nothrow requirements to get back some independence.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution