
--- On Tue, 5/10/11, Gordon Woodhull wrote:
On May 9, 2011, at 10:36 AM, Cromwell Enage wrote:
One current limitation that may be important to you is the inability to supply custom allocators as well. I saw in the sandbox that the BGL authors were planning to provide selector templates parameterized by allocator type. I'm wondering how that work is progressing.
This appears to be documented at http://www.boost.org/doc/libs/1_39_0/libs/graph/doc/using_adjacency_list.htm...
At least, they say how to do it, but one would need to double the number of tags and container_gen specializations in order to fully support allocators this way, along with all the other traits. What are you referring to in the sandbox?
I was referring to BGL v2, but now I see that list_with_allocator is actually provided as an example by the current BGL. My mistake.
At any rate, to the BGL authors: I find container_gen to be a useful utility metafunction outside its current home. Would anyone else like to see it become a first-class Boost citizen?
Yes, please. I need container_gen for the proposed Fusion.Graph. (basic prototype in sandbox/metagraph/fusion_graph).
Neato! I'll have to check it out sometime.
You are proposing to split it out into its own header, right? Should it go into Utility? Or maybe it is Graphy enough to stay where it is. Will you be using parallel_edge_traits and is_random_access as well?
I'm using container_gen in enough situations outside the BGL for it to warrant its own home. This along with is_random_access_selector--this name seems more accurate--and associative_container_gen, a companion metafunction I wrote, are small enough to join Boost.Utility, I think. The parallel_edge_traits template can stay in BGL.
I guess container_gen corresponds to/belongs with potentially a whole library of container traits. I see that a few container traits libraries have been proposed in the past (one turned into Range). It's another library for library authors.
I see container_gen as a type-generating metafunction rather than a trait-querying metafunction, although I can also see potentially heavy interaction between container_gen and container traits libraries.
I need to generalize container_gen to pretend that a pointer or smart pointer, optional or plain containment are simple sorts of containers, where the size is 0 or 1. I suppose this is just a matter of writing a bunch of adaptors, and using container_gen as-is.
Gotcha.
Cheering you on with the Tree stuff,
Thanks! Cromwell D. Enage