Re: Inconsistent behaviour for certain conditional expressions

The example I concocted was for illustration only.

The place where using this kind of construct is useful is when doing a
type of RAiI (Resource Aquisition is Initialization):

class Lock
{
 Resource& r;
 operator bool();
 ~Lock(){r.Release();}
};

class Resource
{
 void Release();
 Lock Acquire();
};

Now, normally you would write code like this:

Resource r;
const Lock l = r.Aquire();
if (l)
{
etc....
}

The problem is that the Lock l variable is in the scope outside the
conditional block. This means that you can't make the automatic
destructor call free the resource at the end of the conditional block.

Now observe this code:
if (const Lock l = r.Aquire())
{

}

Not only is the code smaller, the lock only exists in the scope of the
conditional block.

What I had in my older code was a expression that looked like:
if (const Lock l(r))....

which I think is better looking and avoids the problematic style of
using the the assignment operator in a conditional expression (the
classic error of writing a=b, instead of a==b)

If somebody can suggest a more elegant way of doing RAiI than the one I
illustrated above, I am all ears.

thanks.

Tom Serface wrote: