I was wondering, what exactly gets saved in a context pointer?

Is it the equivalent of [&] in C++? Is there anything copied by value? Is there a way to do that?

On Monday, 27 January 2014 at 02:56:44 UTC, Etienne Cimon wrote:
> I was wondering, what exactly gets saved in a context pointer?
>
> Is it the equivalent of [&] in C++? Is there anything copied by value? Is there a way to do that?

D delegates work differently from C++ closures.

A delegate is a "fat pointer" - it is the aggregate of a function pointer and a context pointer - so the size of a delegate is always the size of two pointers, no matter what they point to. The function pointer points to a non-static nested function or a struct/class non-static member function. The context pointer points to a stack frame, a struct/class instance or a GC-heap-allocated copy of a stack frame (heap-allocated closure). The context pointer is needed so the function can refer to its upvalues, such as outer local variables for a nested function, or member fields for a member function. In all cases the calling convention is the same, which means that a delegate retrieved from a member function and one retrieved from a nested function are interchangeable as long as they have the same parameter types and return type.

A copy is only made if the closure needs to be moved to the heap to avoid escaping references to stack memory beyond its lifetime. This is why it's safe to return delegates retrieved from nested functions from the outer function, even though the nested functions can refer to local variables.

C++ closures work similarly to D non-static nested structs: they carry copies or references to upvalues as hidden members of their type. In C++, this type is unnamed - there is no syntax for it, it can only be referred to with type inference (such as by wrapping it with std::function). In D, nested structs are named but the scope of the name is limited - once the struct instance leaves the function, it is no longer identifiable by name, which is the reason for their moniker "voldemort type".

By the way, this kind of question is best aimed at the D.learn group :)

On 2014-01-26 22:20, Jakob Ovrum wrote:
>
>
> C++ closures work similarly to D non-static nested structs: they carry
> copies or references to upvalues as hidden members of their type. In
> C++, this type is unnamed - there is no syntax for it, it can only be
> referred to with type inference (such as by wrapping it with
> std::function). In D, nested structs are named but the scope of the name
> is limited - once the struct instance leaves the function, it is no
> longer identifiable by name, which is the reason for their moniker
> "voldemort type".

That must be why the only way to refer to those nested struct types is by returning auto and using typeof on the variable that absorbs the value.

I was mostly wondering if the return values of static structs used inside the closure would be captured within that closure. I see it's only about local variables or other outer instances, so if I add a closure to a dynamic delegate array it should allow me to pick up a new pointer returned by the static struct.

I love your work on LuaD btw, I'm using it as the first step of runtime as a configuration file in a vibe.d cms/framework, and also as a vibe.d runtime page (I intend to pass over most of my convenience functions to luastate). It allows me to have configuration namespaces with comments, which is the most precious dependency of a library-based CMS. You can see an example of how I'm using it here: https://github.com/GlobecSys/w3Vibe/blob/master/examples/luadebugger/config.lua

Thanks!