On Thu, Dec 05, 2013 at 08:46:52AM -0800, 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. [...]
I got your point from your previous post. It made me wonder how something like, say, a directed graph could be constructed in a way such that the caller gets to control how memory is allocated. My first thought was to use an abstract factory object that exposes an API that allowed construction of nodes and edges. The function would take this API as argument, and the caller provides the actual implementation. However, on further thought, this doesn't address the case when the function needs to do something opaque to the API, such as creating a derived class of a graph node (assuming the API has some kind of method that allocates and creates nodes). Ultimately, it seems that an allocator is the only way that doesn't make the caller/callee interface extremely ugly and leaky. T -- People tell me I'm stubborn, but I refuse to accept it!
