Any way to track memory allocations?

[Daniel Keep]

Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
> <daniel.keep.lists at gmail.com> wrote:
> 
>> Yup.
>>
>> It's a pity that we don't have, oh I don't know, some sort of efficient
>> iterable interface that doesn't cause a heap allocation that the runtime
>> could use instead *cough*hint*cough*andrei*cough*ranges*cough*.
> 
> You can use "foreach(k; aa)" and "foreach(_, v; aa)".
> 
> The thing is they're not always substitutes for .keys and .values.
> For example, if you want to modify the AA during the foreach loop, you
> have to use something like "foreach(k; aa.keys)" since you need a
> "snapshot" of the keys as they were before you started modifying it.

True; although I'm one of those people who stays up at night, plotting
the gruesome demise of invisible allocations, so I tend to do manually
create and destroy the storage for the keys.

In a perfect world, we'd have extension methods, and then we could just
do this:

RangeType!(T)[] toArray(T)(ref T this) if isRange!(T)
{
  ...
}

foreach( k ; aa.keys.toArray ) ...

My own policy is that if you have to choose between two designs, one
where you always allocate and the other where you can optionally
allocate, go for the second.

  -- Daniel