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
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
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.
> Cheering you on with the Tree stuff,
Cromwell D. Enage
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk