[BGL] container_gen (was Re: [tree] reviving the tree library)
--- On Fri, 5/6/11, Erik Erlandson wrote:
My storage models are effectively wrappers around the underlying containers (the container is a member of the node type). I originally thought it would be nice to allow a user to somehow drop in any container they wanted, but I was unable to find a way to make that work properly.
[snip]
Perhaps container_gen would allow it to be more fully automated.
The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter. 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. 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? Cromwell D. Enage
On May 9, 2011, at 10:36 AM, Cromwell Enage wrote:
The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter.
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?
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). 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 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 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. Cheering you on with the Tree stuff, Cheers, Gordon
--- 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
On Mon, 9 May 2011, Cromwell Enage wrote:
--- On Fri, 5/6/11, Erik Erlandson wrote:
My storage models are effectively wrappers around the underlying containers (the container is a member of the node type). I originally thought it would be nice to allow a user to somehow drop in any container they wanted, but I was unable to find a way to make that work properly.
[snip]
Perhaps container_gen would allow it to be more fully automated.
The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter.
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.
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?
I would be happy to see it as a separate component, plus potentially updated with more container types (Boost.Intrusive, Boost.Interprocess, etc.) as well as allocators, which have been desired for a while in BGL. -- Jeremiah Willcock
On May 11, 2011, at 12:02 AM, Jeremiah Willcock wrote:
I would be happy to see it as a separate component, plus potentially updated with more container types (Boost.Intrusive, Boost.Interprocess, etc.) as well as allocators, which have been desired for a while in BGL.
I will need Intrusive so I can help with that... very interesting properties to intrusive containers. They are very appropriate for graph data structures because the vertices & edges tend to be indexed in many different ways, and an intrusive design eliminates all the little objects you get from list<T*> or set<T*>.
On May 14, 2011, at 5:54 AM, Gordon Woodhull wrote:
I will need Intrusive so I can help with that... very interesting properties to intrusive containers.
There might have to be a little bit of containee_gen here, an interface to get the types that should be included by inheritance or containment in e.g. the vertices and edges of the incidence_list. It would return something empty for non-intrusive containers.
participants (3)
-
Cromwell Enage -
Gordon Woodhull -
Jeremiah Willcock