Re: goto... is it so bad?
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++.
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.
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.
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.
3) combining common error exits
"goto nomatch;" requires the reader to go down to see if there's
something else than the sole return statement.
The single-entry, single-exit paradigm has value, too.
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.
Regards
Vladimir Marko
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]