Re: [boost] [BGL] container_gen (was Re: [tree] reviving the tree library)

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 
> http://www.boost.org/doc/libs/1_39_0/libs/graph/doc/using_adjacency_list.html#sec:custom-storage
> 
> 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