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
