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.
