Boost logo

Boost :

Subject: Re: [boost] [BGL] container_gen (was Re: [tree] reviving the tree library)
From: Cromwell Enage (sponage_at_[hidden])
Date: 2011-05-10 10:03:30

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at