|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-02-11 16:36:44
"Peter Dimov" <pdimov_at_[hidden]> writes:
> David Abrahams wrote:
>
>> And how can I understand what you're saying well enough to convince
>> implementors that I'm right?
>
> I think that the first thing to do is to ask implementors why they require
> the accessible copy constructor for f( X(1) ), while at the same time the
> seemingly equivalent f( XC(X(1)) ) (as per the infamous second bullet)
> compiles fine.
That argument won't fly with Microsoft, since in strict mode they
reject f( XC(X(1)) ). And shouldn't they, after all? The problem is
that operator ref() is non-const, so you can't apply the loophole
again to copy XC(X(1)) [which ability is required per 8.5.3/5].
I don't find the failure of f(XC(X(1)) compelling, though, because
IIUC the final XC conversion you've spelled out there really
represents the last "copy" in the sequence of copies allowed to the
compiler.
Still I now have to wonder why this test passes VC7.1 in strict mode:
X const& r = XC();
Since it is also binding a const reference to a const rvalue (which
can't be copied using a copy ctor), while test 11 does not:
sink2(csource());
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk