On Wednesday, 9 March 2016 at 01:18:26 UTC, maik klein wrote:
> Direct link: https://maikklein.github.io/post/CppAndD/
> Reddit link: https://www.reddit.com/r/programming/comments/49lna6/a_comparison_between_c_and_d/
>
> If you spot any mistakes, please let me know.

I'm missing the wildcard modifier inout (even if it's a ugly name), which inherits constness automatically. That is really awesome.

On Wednesday, 9 March 2016 at 18:26:01 UTC, bigsandwich wrote:
> On Wednesday, 9 March 2016 at 01:18:26 UTC, maik klein wrote:
>> [...]
>
> C++ as well as D have anonymous functions. C++: [](auto a, auto b){ return a + b;} , D: (a, b) => a + b or (a, b){return a + b;}. As far as I know capturing other variables requires the GC in D. In C++ you can explicitly capture variables by copy, ref or move. Lambda functions in D can not return references. C++17 will also make lambda functions available with constexpr. Lambda functions can also be used at compile time in D.
>
> Is this really true?  Couldn't the closure be stored internally somewhere like std::function<> does in C++?

I think this is actually not true, but I wrote it because of this

http://dpaste.dzfl.pl/dd6b935df5ce

I run into this problem a couple of times.

On Wednesday, 9 March 2016 at 18:26:01 UTC, bigsandwich wrote:
> Is this really true?  Couldn't the closure be stored internally somewhere like std::function<> does in C++?

Lambdas in C++ creates a regular class with a call-operator, the class is instantiated and the fields filled with the "captured" variables. Isn't std::function<> just for supporting passing of lambdas etc when using separate compilation? I've never used it since I assume it is very slow. I always use function objects with a templated type in C++.

But I believe D is pointing to the activation record (stack frame) and not the individual variables. So I don't think D can capturing anything by value. Or is this wrong?

On Wednesday, 9 March 2016 at 18:26:01 UTC, bigsandwich wrote:
> As far as I know capturing other variables requires the GC in D.

You can easily do it yourself with a struct. That's all the c++ lambda is anyway, a bit of syntax sugar over a struct.

Then you pass the struct itself if you want the variables carried with it, or allocate it somewhere and pass a reference to the call operator as a plain delegate.

Let me go into some detail:

---
import std.stdio;

@nogc int delegate(int) dg;

int helper() @nogc {
	int a = 50;
	dg = (b) {
		return a + b;
	};

	return dg(10);
}

void main() {
	writeln(helper());
}
---

That won't compile because it wants to allocate a closure for the escaped variable, `a`. How do we get around it?

While keeping the delegate:

---
import std.stdio;

@nogc int delegate(int) dg;

int helper() @nogc {
	int a = 50;

	struct MyFunctor {
		int a;

		@nogc this(int a) { this.a = a; }

		// the function itself
		@nogc int opCall(int b) { return a+b; }
	}

	// capture a by value
        // WARNING: I stack allocated here but
        // set it to a global var, this is wrong;
        // it should probably be malloc'd, but since
        // I know I am just using it here, it is OK
	auto myfunc = MyFunctor(a);

	dg = &myfunc.opCall;

	return dg(10);
}

void main() {
	writeln(helper());
}
---


Like the comment in there says, if you are actually going to be storing that delegate, you need to tend to the lifetime of the object somehow.

That's a big reason why the GC makes this a lot *nicer* because it alleviates that concern, but it isn't *required* - you can still manage that object manually if you use the right kind of manual caution.

But better is probably to forget the delegate itself (except maybe passing it to some places) and actually store that object. Then you can pass it by value or refcount it or whatever traditional technique you want.

With opCall, this thing counts as functor and std.algorithm will treat it as a function too.


What if you want some syntax sugar? Eeeeh, I don't have a full solution for that right now, but you could kinda do a mixin template or a string thing or something, but I think just doing the struct yourself isn't really that bad.

On Wednesday, 9 March 2016 at 20:14:13 UTC, Adam D. Ruppe wrote:
> On Wednesday, 9 March 2016 at 18:26:01 UTC, bigsandwich wrote:
>> [...]
>
> You can easily do it yourself with a struct. That's all the c++ lambda is anyway, a bit of syntax sugar over a struct.
>
> [...]

Right,  I used to this sort of thing in C++ prior to C++11.  I think not having an RAII wrapper for lambdas similar to std::function<> is an oversight for D, especially for people averse to GC.  That little bit of syntactic sugar makes a huge difference.

On Wednesday, 9 March 2016 at 20:41:35 UTC, bigsandwich wrote:
> Right,  I used to this sort of thing in C++ prior to C++11.  I think not having an RAII wrapper for lambdas similar to std::function<> is an oversight for D, especially for people averse to GC.  That little bit of syntactic sugar makes a huge difference.

std::function<> is a lot more than syntactic sugar, it is a runtime-heavy construct. From http://en.cppreference.com/w/cpp/utility/functional/function :

«Class template std::function is a general-purpose polymorphic function wrapper. Instances of std::function can store, copy, and invoke any Callable target -- functions, lambda expressions, bind expressions, or other function objects, as well as pointers to member functions and pointers to data members.»

I don't think you want this...

On Wednesday, 9 March 2016 at 22:05:28 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 9 March 2016 at 20:41:35 UTC, bigsandwich wrote:
>> Right,  I used to this sort of thing in C++ prior to C++11.  I think not having an RAII wrapper for lambdas similar to std::function<> is an oversight for D, especially for people averse to GC.  That little bit of syntactic sugar makes a huge difference.
>
> std::function<> is a lot more than syntactic sugar, it is a runtime-heavy construct. From http://en.cppreference.com/w/cpp/utility/functional/function :
>
> «Class template std::function is a general-purpose polymorphic function wrapper. Instances of std::function can store, copy, and invoke any Callable target -- functions, lambda expressions, bind expressions, or other function objects, as well as pointers to member functions and pointers to data members.»
>
> I don't think you want this...

Yes, I do.  std::function<> uses type erasure to store a "function".  If its small enough, its stored internally, otherwise it goes on the heap.  It uses RAII to manage the lifetime of the lambda.  D is using the GC for managing the lifetime.  D doesn't have a way of doing this without the GC.

On Wednesday, 9 March 2016 at 22:54:13 UTC, bigsandwich wrote:
> On Wednesday, 9 March 2016 at 22:05:28 UTC, Ola Fosheim Grøstad wrote:
>> [...]
>
> Yes, I do.  std::function<> uses type erasure to store a "function".  If its small enough, its stored internally, otherwise it goes on the heap.  It uses RAII to manage the lifetime of the lambda.  D is using the GC for managing the lifetime.  D doesn't have a way of doing this without the GC.

D can do it too, there's just no syntactic sugar for it.

Atila

On Wednesday, 9 March 2016 at 20:14:13 UTC, Adam D. Ruppe wrote:
> ---
> import std.stdio;
>
> @nogc int delegate(int) dg;
>
> int helper() @nogc {
> 	int a = 50;
>
> 	struct MyFunctor {
> 		int a;
>
> 		@nogc this(int a) { this.a = a; }
>
> 		// the function itself
> 		@nogc int opCall(int b) { return a+b; }
> 	}
>
> 	// capture a by value
>         // WARNING: I stack allocated here but
>         // set it to a global var, this is wrong;
>         // it should probably be malloc'd, but since
>         // I know I am just using it here, it is OK
> 	auto myfunc = MyFunctor(a);
>
> 	dg = &myfunc.opCall;
>
> 	return dg(10);
> }
>
> void main() {
> 	writeln(helper());
> }

typeof(&myfunc.opCall) == int delegate(int b) @nogc

what magic is this? I had no idea that taking the address of opCall would give me a delegate.

On Thursday, 10 March 2016 at 00:31:00 UTC, John Colvin wrote:
> what magic is this? I had no idea that taking the address of opCall would give me a delegate.

opCall is a red herring: taking the address of *any* non-static member function in a class or struct object will give you a delegate.

(Addresses of static member function will give you a function pointer, and so will taking the address of ClassName.memberName. But classObject.memberName is a delegate because there is a this pointer attached.)