Memory allocation purity

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon May 19 06:42:31 PDT 2014


On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d  
<digitalmars-d at puremagic.com> wrote:

> On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via  
> Digitalmars-d wrote:
>> On Thu, 15 May 2014 08:43:11 -0700
>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
>> wrote:
>>
>> > On 5/15/14, 6:28 AM, Dicebot wrote:
>> > > This is not true. Because of such code you can't ever
>> > > automatically memoize strongly pure function results by compiler.
>> > > A very practical concern.
>> >
>> > I think code that doesn't return pointers should be memoizable.
>> > Playing tricks with pointer comparisons would be appropriately
>> > penalized. -- Andrei
>>
>> Agreed. The fact that a pure function can return newly allocated
>> memory pretty much kills the idea of being able to memoize pure
>> functions that return pointers or references, because the program's
>> behavior would change if it were to memoize the result and reuse it.

Memoizing reference returns that are immutable should be fine.

>> However, that should have no effect on pure functions that return
>> value types - even if the function took pointers or references as
>> arguments or allocated memory internally. They should but perfectly
>> memoizable.
> [...]
>
> 	bool func(int x) /* pure? */ {
> 		int[] a, b;
> 		a = new int[x];
> 		b = new int[x];
> 		return (a.ptr < b.ptr);
> 	}
>
> Where do you draw the line?

Definitely this is fine being pure, and can be memoized. It just won't do  
what you thought it would. So? :)

This is what Andrei meant as being "penalized."

-Steve


More information about the Digitalmars-d mailing list