RE: [boost] [Review] Boost Graphs Library (GGCL)

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-08-30 11:58:08

>  - For the adjacency_list, the selectors are the wrong design, because
> they limit the choice of base containers to a fixed set.  Use
> template template parameters instead, that's what they're there for.
> Plus, that's the first real use of template template parameters I
> can see :-)
> 
Ok, at first I was confused about this comment but it makes sense now:

The request for those who don't use template template parameters is to
change the class adjacency_list to 

template< class value_type,
         template<class ValueType,
                  class Allocator > EdgeListS = ,
          ...
        >

      class adjacency_list {};

It would require users of a new container to create a cover template to only
take two class arguments, just as the container_gen<> template does now. And
it would require that the value_type be specified.

It might make sense to instead of sending in a cover template, to just
specify the container, not use template template arguments, but instead a
class.  Otherwise the defaults could get ugly. It kind of bugs me that to
specify a vector, I send in vecS, instead of vector<>. But I understand how
this sort of thing falls into your code.

This change is definitely a shotgun change, a lot of places in the code
would change. i.e. the adjacency_iterator instead of relying on the struct
VecS to tell it what type of iterator it was, would have to do container
iterator evaluation. It percolates everywhere.

On the other hand, not being able to add a new base container is a serious
design problem for something in "std", as we have all seen when we tried to
make specializations of "swap". i.e., you can't modified "std". Otherwise it
isn't "std" now is it?"  :>

I'd offer to help make this change but I'd probably make a bigger mess of
things, not fully understanding the underlying design.

  Yours Truly,
  -Gary-

gary.powell_at_[hidden] 

PS
  The VTL library has some of these same problems with std containers, i.e.
figuring out their traits. It might be worth it to make a stltraits.h
combined file. I bet that we want to know the same basic sort of
information. Plus as an addition to the "std" library stltraits fits in with
iterator_traits very well on its own.

PPS

  On using template template parameters, the VTL library had good luck with
using them, where we controlled the parameter completely, i.e. the details
of the template passed in were an implementation detail which we didn't need
to expose to the user, and users weren't expected to create new ones.