Use case: eliminate hidden allocations in buildPath

[monarch_dodra]

On Thursday, 5 December 2013 at 18:34:40 UTC, Andrei Alexandrescu 
wrote:
> Trees and graphs are not special cases. They're bread and 
> butter objects with fields that are in turn allocated etc.

Yes, and they aren't really linear containers either, but that 
doesn't mean we throw the input range concept out the window.

The graph itself could carry the allocator, and just the same you 
have a function "getNeighbors" that returns an input range of a 
node's neighboring nodes, the graph could also give a collection 
of different ouput ranges that takes care of allocation.

I'm just saying it's not something I'd like to see that 
*functions* take allocators as arguments. I think that should be 
abstracted by the containers/ranges themselves, in such a way 
that the functions only have to use things like "pushBack" (eg: 
std::back_inserter).

> 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.

I'm out of my league on this one.