Re: goto... is it so bad?
Vladimir Marko wrote:
On 28 Mar, 02:02, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
Vladimir Marko wrote:
On 26 Mar, 23:13, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
... For simple things
const scope_exit& dummyName = bind(&Foo::Finish,foo);
should do. Well, anonymous references would help too.
I view those complaints as being crippling shortcomings. Setting that
aside for the moment, which do you think is more straightforward:
const scope_exit& dummyName = bind(&Foo::Finish,foo);
or:
scope (exit) foo.Finish();
?
I'd prefer
SCOPE(exit) foo.Finish;
where SCOPE is a properly defined macro -- I'm not calling
foo.Finish() now, I'm just scheduling the function object for
delayed invocation. Unfortunately, closures cannot be formed
as object.member_function in C++.
Right - it doesn't work in C++. And if you find you have to use macros
to invent syntactical constructs, well, those kind of things always make
me uneasy.
And before you mention scope(success) and scope(failure),
Too late <g>.
the problem in
C++ is not with RAII; it's with the std::uncaught_exception being
insufficient to determine whether to execute the code or not.
I don't understand.
A naive implementation of scope(failure) is
const scope_exit& dummy = boost::lambda::if_then(
&std::uncaught_exception,
failure_functor);
The problem is that std::uncaught_exception() might return true
if examined while constructing the scope_exit object and then it
will be true even if we exit the scope without throwing. Example:
struct Evil{
~Evil()
try
{
const scope_exit& dummy = boost::lambda::if_then(
&std::uncaught_exception,
&undo);
throwing_function();
}
catch(...) { }
};
If an Evil object is being destroyed during stack unwinding,
undo will be called regardless of whether throwing_function
throws or not.
Fortunately, scope(success) and scope(failure) are easily and robustly
implementable using try-catch-finally:
scope(failure) s;
=> try { ... } catch (o) { s; throw o; }
scope(success) s;
=> int x=0; try { ... } catch (o) { x = 1; throw o; } finally { if (!x) s; }
Second, creating _objects_ "for the sole purpose of manipulating
control flow" is the very best way of writing exception safe (and
IMO also simple and maintainable) code.
This is certainly the conventional wisdom. But the cracks in it are
slowly becoming better known, seehttp://www.digitalmars.com/d/exception-safe.htmlandhttp://www.ddj.com/dept/cpp/184403758. The biggest crack is when you
have a sequence of operations that must either all succeed or all fail.
RAII doesn't do well with this, and try-finally is even worse.
I can see many deficiencies of C++ that make RAII more complicated
than it has to be but I fail to see the cracks in RAII itself.
If you're willing to accept the necessarily contorted method and
crippling deficiencies of doing scope guards in C++, I agree you can get
the job done that way.
My favorite solution for this is actually the scope guard
statement:http://www.digitalmars.com/d/exception-safe.html
invented by Andrei Alexandrescu and Petru Marginean
Is this not RAII? Is my definition of "resource" much broader
than yours?
It isn't RAII any more than try-finally is RAII.
Apparently, you didn't get my point. Every single ScopeGuard takes
ownership of "resources" allocated for some kind of "transaction".
Thus, ScopeGuard is a RAII tool by definition. My definition.
You're right, I didn't get your point. But I don't agree with your
definition because it tries to redefine the problem in a way that
doesn't help.
BTW, the scope guard statement is implemented internally in the compiler
by transforming it into a combination of try-catch-finally statements.
So are RAII objects.
I'm no fan of SESE. It's always been PITA when I used it.
IMO, with goto you pretend to use the SESE while actually
having multiple returns.
You could look at it that way. But there is another, subtler reason I do
it. With most CPUs, faster code is the branch not taken. So I'll use
gotos to get the uncommon cases out of the direct control flow.
Sometimes the result isn't the prettiest, but when you feel the need for
speed..
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]