opApply and that int
Bill Baxter
dnewsgroup at billbaxter.com
Fri Jan 4 04:12:46 PST 2008
I know we've been through this before but I don't recall the conclusion.
Why do we have to pass an int through our opApply functions.
Given an object.opApply that takes a delegate that takes a ref T,
and code like this:
foreach(T x; object) {
if (x) break;
if (condition) return Something;
do_something;
}
the compiler transforms that into something like this:
RType _fn_ret; // (RType is return type of enclosing function)
int _loop_body(ref T x)
{
if (x) return BREAK;
if (condition) { _fn_ret = Something; } return RETURN;
do_something;
return 0;
}
int _ret = object.opApply(&_loop_body));
if (_ret==RETURN) return;
else if (_ret==GOTO) goto ??;
// maybe some other cases...
My question is this: _loop_body and the caller of opApply share the same
enclosing scope, so why not stick the return code in a local variable
both can see? It already seems to do that that for return values (as
far as I can tell from reading dmd/src/dmd/statement.c). So why not do
it for the main return code too and generate code like this:
RType _fn_ret;
int _ret = 0;
void _loop_body(ref T x)
{
_ret = 0;
if (x) { _ret = BREAK; return; }
if (condition) { _fn_ret = Something; _ret = RETURN; return; }
do_something;
}
object.opApply(&_loop_body));
if (_ret==RETURN) return;
else if (_ret==GOTO) goto ??;
// maybe some other cases...
Why oh why does that int have to go traipsing through *my* opApply?
--bb
More information about the Digitalmars-d-learn
mailing list