Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
August 30, 2015 Challenge | ||||
---|---|---|---|---|
| ||||
import std.algorithm, std.range; auto foo(R)(R a, immutable int b) { return a.map!(x => x + b); } unittest @nogc @safe { int[] test = [1,2,3]; assert(test.foo(3).equal(only(4,5,6))); } Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map |
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote: > import std.algorithm, std.range; > > auto foo(R)(R a, immutable int b) > { > return a.map!(x => x + b); > } > > unittest @nogc @safe > { > int[] test = [1,2,3]; > > assert(test.foo(3).equal(only(4,5,6))); > } > > Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map import std.algorithm, std.range; auto foo(R)(R a, immutable int b) { return a.map!(x => x + b); } @nogc @safe unittest { int[3] test = [1,2,3]; assert(test[].foo(3).equal(only(4,5,6))); } does this count? |
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to rsw0x | On Sunday, 30 August 2015 at 10:21:20 UTC, rsw0x wrote:
> On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
>> import std.algorithm, std.range;
>>
>> auto foo(R)(R a, immutable int b)
>> {
>> return a.map!(x => x + b);
>> }
>>
>> unittest @nogc @safe
>> {
>> int[] test = [1,2,3];
>>
>> assert(test.foo(3).equal(only(4,5,6)));
>> }
>>
>> Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map
>
> import std.algorithm, std.range;
>
> auto foo(R)(R a, immutable int b)
> {
> return a.map!(x => x + b);
> }
>
> @nogc @safe unittest
> {
> int[3] test = [1,2,3];
>
> assert(test[].foo(3).equal(only(4,5,6)));
> }
>
> does this count?
Oh, I think I see what you were asking. It doesn't compile with LDC, but it compiles just fine with latest DMD.
hmm
|
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
> import std.algorithm, std.range;
>
> auto foo(R)(R a, immutable int b)
> {
> return a.map!(x => x + b);
> }
>
> unittest @nogc @safe
> {
> int[] test = [1,2,3];
>
> assert(test.foo(3).equal(only(4,5,6)));
> }
>
> Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map
Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting...
Carry on, nothing to see here...
|
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Sun, 2015-08-30 at 10:38 +0000, John Colvin via Digitalmars-d wrote: > On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote: > > import std.algorithm, std.range; > > > > auto foo(R)(R a, immutable int b) > > { > > return a.map!(x => x + b); > > } > > > > unittest @nogc @safe > > { > > int[] test = [1,2,3]; > > > > assert(test.foo(3).equal(only(4,5,6))); > > } > > > > Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map > > Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting... So what was the problem? > Carry on, nothing to see here... See above… -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | On Sunday, 30 August 2015 at 11:21:34 UTC, Russel Winder wrote: > On Sun, 2015-08-30 at 10:38 +0000, John Colvin via Digitalmars-d wrote: >> On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote: >> > [...] >> >> Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting... > > So what was the problem? > >> Carry on, nothing to see here... > > See above… https://issues.dlang.org/show_bug.cgi?id=14982 was confusing me. |
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to rsw0x | On Sunday 30 August 2015 12:21, rsw0x wrote: > import std.algorithm, std.range; > > auto foo(R)(R a, immutable int b) > { > return a.map!(x => x + b); > } > > @nogc @safe unittest > { > int[3] test = [1,2,3]; > > assert(test[].foo(3).equal(only(4,5,6))); > } > > does this count? I think this shouldn't compile and it only does so because of issue 14771. https://issues.dlang.org/show_bug.cgi?id=14771 The delegate in foo uses a local variable and it's returned from the function, so it needs a closure. Where does the closure go if not on the GC heap? See also this Learn thread about how to call map with a delegate in a @nogc function: http://forum.dlang.org/post/kpwbtskhnkkiwkdsfzby@forum.dlang.org Ali Çehreli's solution there may or may not actually be @nogc, but I'm afraid it relies on issue 14771 any way: http://forum.dlang.org/post/mqr506$10kf$1@digitalmars.com |
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to anonymous | On Sunday, 30 August 2015 at 13:36:45 UTC, anonymous wrote:
> On Sunday 30 August 2015 12:21, rsw0x wrote:
>
>> [...]
>
> I think this shouldn't compile and it only does so because of issue 14771.
>
> https://issues.dlang.org/show_bug.cgi?id=14771
>
> The delegate in foo uses a local variable and it's returned from the function, so it needs a closure. Where does the closure go if not on the GC heap?
>
> See also this Learn thread about how to call map with a delegate in a @nogc function:
>
> http://forum.dlang.org/post/kpwbtskhnkkiwkdsfzby@forum.dlang.org
>
> Ali Çehreli's solution there may or may not actually be @nogc, but I'm afraid it relies on issue 14771 any way:
>
> http://forum.dlang.org/post/mqr506$10kf$1@digitalmars.com
Is there any reason that closure in this particular example can't be created on the stack? Seems a bit weird.
|
August 30, 2015 Re: Challenge | ||||
---|---|---|---|---|
| ||||
Posted in reply to rsw0x | On Sunday 30 August 2015 16:43, rsw0x wrote:
> Is there any reason that closure in this particular example can't be created on the stack? Seems a bit weird.
It may be possible to store it on the stack somehow, or as part of the map struct. I don't know.
The point is, that's not what happens. It goes on the GC heap, breaking @nogc.
|
Copyright © 1999-2021 by the D Language Foundation