From: Mark Deric (laguna_at_[hidden])
Date: 2005-02-15 17:33:21
On Tue, 15 Feb 2005 03:04:35 +0200
"Peter Dimov" <pdimov_at_[hidden]> wrote:
> >>> struct Dummy { int a; }
> >>>
> >>> class Lock {
> >>> private:
> >>> Dummy &_d;
> >>> public:
> >>> Lock( Dummy &d ) : _d(d) { std::cout << "Locked." << std::endl; }
> >>> ~Lock( void ) { std::cout << "Unlocked." << std::endl; }
> >>>
> >>> Dummy *operator->( void ) { return &_d; }
> >>> };
> >>>
> >>> class Ref {
> >>> private:
> >>> Dummy &_d;
> >>> public:
> >>> Ref( Dummy &d ) : _d(d) { }
> >>>
> >>> Lock operator->(void) { return Lock(_d); }
> >>> };
> >
> >> Your code is non-portable. You are assuming that the temporary
> >> Lock(_d) will be constructed directly in the return value, but this
> >> is not guaranteed.
> >
> > I'm not sure I'm following "constructed directly in the return
> > value"; but, it will be constructed before the call to Lock's Dummy
> > *operator->(
> > void ) as implied by x->a, below. Isn't this all that is required?
>
> No, because ~Lock will be called twice.
Fair enough. I guess I was willing to overlook the absence of a copy
ctor in Raz's pseudo-code that "does the right thing".
The thing that I took away from the idea was the forced creation of a
temporary that is scoped to the remaining duration of evaluation of the
"full-expression" as presented in 12.2 of the standard. Yes, I did need
to look it up :) ; as I was operating under the bogus belief that
destruction of the temporary was a { ... } scoped thing and may be
implementation dependent. Further, I'm used to following the {
scoped_lock lk(mtx); ... } formula; making Raz's idea intriguing, at
least.
I guess the second paragraph of your initial reply gets at the point; is
locking to "full-expression" scope useful? I can think of a danger:
cout << x->a << long_running_overloaded_insertion_rhs;
>From my read, the lock wouldn't be given up until after the second <<
gets evaluated. Does this make sense; or am I missing something else?