Use case: eliminate hidden allocations in buildPath

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Dec 5 10:34:40 PST 2013


On 12/5/13 9:06 AM, monarch_dodra wrote:
> On Thursday, 5 December 2013 at 16:46:52 UTC, Andrei Alexandrescu wrote:
>> On 12/5/13 8:19 AM, monarch_dodra wrote:
>>> On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
>>>> Andrei
>>>
>>> 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.
>>
>> Andrei
>
> Say, something like a graph? At that point, I'd say you'd have to pass
> an "allocating scheme" to the function, so an allocator, yes. Depending
> on the data being generated, the constructed item could carry the
> allocator itself. For example: auto newNode = myNode.GenerateNeighbor();
>
> In But I think that'd be a special case situation. For everything else,
> output range is an easy and intuitive, and fits well with the rest of
> phobos. We'd want (IMHO) to integrate the allocators directly inside the
> output ranges.

Trees and graphs are not special cases. They're bread and butter objects 
with fields that are in turn allocated etc.

Consider how difficult it would be (for both the implementer and the 
user) to fill via an output range an object (class or struct) that has a 
few fields that need allocation (such as strings and arrays). It becomes 
a mini-serialization project. We can't realistically propose that as a 
way to allow users to control memory allocation.


Andrei



More information about the Digitalmars-d mailing list