Re: goto... is it so bad?
Vladimir Marko wrote:
On 29 Mar, 06:22, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
Vladimir Marko wrote:
On 28 Mar, 02:02, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
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.
The other option is to add a new keyword and I don't like that
at all. Why adding to core language if we can implement it as
a library?
Because it doesn't work in the library, for the reasons mentioned.
scope(success) s;
=> int x=0; try { ... } catch (o) { x = 1; throw o; } finally { if (!x) s; }
What about
{ ...; scope(success) expression; ...; }
=>
{ ...; ...; expression; }
I goofed, that should be for scope(failure), with if(x).
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.
Compiler implementation details should not any have impact on
the application code.
They inevitably do, because code must eventually run on a physical
machine with all its imperfections. But in any case, I mentioned this to
point out the semantic equivalence of the constructs. I can also
implement virtual functions in C code (I've seen it done), but I don't
think many would advocate removal of the syntactic sugar that C++ offers
for this.
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..
Do you have any evidence that it's better than profiler-guided
optimization?
Just about everything I've read about writing fast assembler code says
that the fastest code will be the branch not taken. This includes the
guides put out by the CPU vendors.
And yes, I use profilers. I even wrote one:
http://www.digitalmars.com/ctg/trace.html
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]