weird behavior returning delegate

[Carlos Santander]

Sean Kelly escribió:
> Carlos Santander wrote:
>> Sean Kelly escribió:
>>>
>>> It's because you're using one function to do the asserts and another 
>>> to print results, so the values returned from acc1 and acc2 may be 
>>> different.  I combined the two cases by storing the result in a 
>>> number then performing the assert, etc, and the errors corresponded 
>>> with what was displayed.
>>>
>>
>> I did the same too, but that's what I don't understand: what are 
>> really the correct values, the ones that are printed or the ones that 
>> pass the asserts?
> 
> When you enter the realm of undefined behavior, anything goes.  In this 
> case I think the residual stack data is just a bit different in foo() 
> and bar(), possibly because bar() is called before foo() or simply as an 
> artifact of different code generation, so the calls that break are 
> different in each case.
> 
>> Also, I don't think putting them in one, two or more functions really 
>> matters. I would expect the previous acc1 and acc2 to be gone when the 
>> function exits.
> 
> Yes but the delegates are referencing invalid stack locations, and so 
> there's no guarantee that the data will be the same even if the basic 
> sequence of calls is similar for both foo() and bar().
> 
>> Anyway, bottom line is I think I'm hoping for too much. Unless 
>> something like Burton's proposed "new delegate" syntax is put into the 
>> language, this wouldn't really work properly.
> 
> Yeah.  I think it might work if acc() accepted 'n' as 'inout', but doing 
> so still seems a bad idea as the delegate's stack context is technically 
> invalid at the point where it's called by foo() and bar().
> 
> 
> Sean

Thanks for the answers. I was hoping D could be added to 
http://www.paulgraham.com/accgen.html only with three lines instead of something 
like that horrible C++ code.

-- 
Carlos Santander Bernal