www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - question about foreach, opApply, and delegates

reply Jerry Quinn <jlquinn optonline.net> writes:
Hi, all.  I find myself a little confused about how foreach, opApply, and
delegates interact according to the docs.

Foreach on an aggregate will use the opApply call (assuming ranges aren't being
used).  So if we use a simple example below, what exactly is the delegate that
is passed to opApply?  The docs say a delegate is a pairing of an object
reference and a function, where the object is passed as the 'this' parameter to
the function.  But that doesn't seem to be the case here.

Is a virtual object with a function encompassing the body of the foreach being
silently created and passed in?

Thanks,
Jerry


class C {
  uint[] a;
  int opApply(int delegate(ref uint) dg) {
    int result = 0;
    for (size_t i=0; i < a.length; i++) {
      result = dg(a[i]);
      if (result) break;
    }
    return result;
  }
}
void foo() {
  C c = new C;
  foreach (uint v; c) { writefln(v); }
}
Jun 08 2009
next sibling parent reply grauzone <none example.net> writes:
Jerry Quinn wrote:
 Hi, all.  I find myself a little confused about how foreach, opApply, and
delegates interact according to the docs.
 
 Foreach on an aggregate will use the opApply call (assuming ranges aren't
being used).  So if we use a simple example below, what exactly is the delegate
that is passed to opApply?  The docs say a delegate is a pairing of an object
reference and a function, where the object is passed as the 'this' parameter to
the function.  But that doesn't seem to be the case here.
 
 Is a virtual object with a function encompassing the body of the foreach being
silently created and passed in?

The foreach body is like a nested function. Your example is (probably, maybe this is wrong/oversimplified) compiled to something like this: void foo() { C c = new C; int bla; void something(uint v) { bla = 123; writefln(v); } c.opApply(&something); } Note that &something is a delegate. A delegate is a pair of a context pointer and a function pointer. As you said, the context pointer can be an object reference. But in this case, it's a raw pointer into the stack. That's why you can use variables declared in the containing function (foo). I added a variable 'bla' to demonstrate this. When the nested function accesses bla, it reads the delegate's context pointer to access the stack frame of the containing function. You could say the foreach statement is a giant pile of syntactic sugar. No magic involved. When the break or continue statements are used, things get more trickier. That's why the delegate passed to opApply returns an int. I think. Also, this should go into the d.D.learn newsgroup. (Although I think it's perfectly fine to post this here, because the "gurus" don't post and probably don't even read d.D.learn.)
Jun 08 2009
parent BCS <none anon.com> writes:
Hello grauzone,

 Jerry Quinn wrote:
 
 Hi, all.  I find myself a little confused about how foreach, opApply,
 and delegates interact according to the docs.
 
 Foreach on an aggregate will use the opApply call (assuming ranges
 aren't being used).  So if we use a simple example below, what
 exactly is the delegate that is passed to opApply?  The docs say a
 delegate is a pairing of an object reference and a function, where
 the object is passed as the 'this' parameter to the function.  But
 that doesn't seem to be the case here.
 
 Is a virtual object with a function encompassing the body of the
 foreach being silently created and passed in?
 


In one way of looking at it every stack frame is a virtual struct <g> so yes, sort of.
 The foreach body is like a nested function. Your example is (probably,
 maybe this is wrong/oversimplified) compiled to something like this:
 
 void foo() {
 C c = new C;
 int bla;
 void something(uint v) {
 bla = 123;
 writefln(v);
 }
 c.opApply(&something);
 }

IIRC if you compile with the -v flag you can even see DMD running code generation for the foreach bodies.
 (Although I think
 it's perfectly fine to post this here, because the "gurus" don't post
 and probably don't even read d.D.learn.)

I may not count as a "guru" but I'm "not a beginner" and do read it.
Jun 08 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jun 8, 2009 at 8:55 AM, Jerry Quinn<jlquinn optonline.net> wrote:
 Hi, all. =A0I find myself a little confused about how foreach, opApply, a=

 Foreach on an aggregate will use the opApply call (assuming ranges aren't=

elegate that is passed to opApply? =A0The docs say a delegate is a pairing = of an object reference and a function, where the object is passed as the 't= his' parameter to the function. =A0But that doesn't seem to be the case her= e.
 Is a virtual object with a function encompassing the body of the foreach =

Sort of. The delegate passed into the opApply in this case is actually the body of the loop. The compiler transforms the foreach loop body into a nested function. Nested functions are delegates, but their context pointer is a pointer to their enclosing function's stack frame rather than to an object. So no object is created, but it still transparently works like a delegate. This is also why in D1 returning nested functions results in undefined behavior: the pointer to the enclosing function's stack frame is no longer valid.
 Thanks,
 Jerry


 class C {
 =A0uint[] a;
 =A0int opApply(int delegate(ref uint) dg) {
 =A0 =A0int result =3D 0;
 =A0 =A0for (size_t i=3D0; i < a.length; i++) {
 =A0 =A0 =A0result =3D dg(a[i]);
 =A0 =A0 =A0if (result) break;
 =A0 =A0}
 =A0 =A0return result;
 =A0}
 }
 void foo() {
 =A0C c =3D new C;
 =A0foreach (uint v; c) { writefln(v); }
 }

Jun 08 2009
prev sibling parent downs <default_357-line yahoo.de> writes:
Jerry Quinn wrote:
 Hi, all.  I find myself a little confused about how foreach, opApply, and
delegates interact according to the docs.
 
 Foreach on an aggregate will use the opApply call (assuming ranges aren't
being used).  So if we use a simple example below, what exactly is the delegate
that is passed to opApply? 

 The docs say a delegate is a pairing of an object reference and a function,
where the object is passed as the 'this' parameter to the function.  But that
doesn't seem to be the case here.

If the docs say that, they're wrong. Generally speaking, a delegate is a pairing of a function pointer and a context, where the context can be a struct pointer, a class reference *or a stackframe*, as is the case with opApply. Hope that clears things up.
Jun 08 2009