Use case: eliminate hidden allocations in buildPath

[Andrei Alexandrescu]

On 12/7/13 5:13 AM, Michel Fortin wrote:
> On 2013-12-05 16:46:52 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 12/5/13 8:19 AM, monarch_dodra wrote:
>>> Output range! :)
>>>
>>> Output range interface makes no linearity requirements. Just that:
>>> "out.put(this)" compiles.
>>
>> Hrm, construction of a hash table is linearizable so bad example on my
>> part. But I'm talking about general structured data such as objects
>> with allocated fields and connections to other objects etc. etc.
>
> You have to admit that a "bump the pointer" allocator is pretty much the
> same thing as an output range that fills a preexisting array.

Only of the output range is untyped. An allocator traffics in untyped 
chunks; an output range usually has an element type.

> So here's an interesting idea: perhaps typed allocators should *be*
> output ranges. The difference is that if you "put" something on the
> allocator, it copies/moves it to the allocator's heap and returns you a
> pointer. While if you "put" something on a generic output range, don't
> expect any pointer out of it.
>
> Some functions, like buildPath, would only require an output range.
> Others will need a more complete allocator, that's those functions that
> want to refer back to elements they've "put" on the allocator's heap.

I don't think that would work.


Andrei