Use case: eliminate hidden allocations in buildPath

[H. S. Teoh]

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!