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

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-08-31 17:13:16

> Gary Powell wrote:
> > Jeremy wrote:
> > > The problem with this is that the value_type that will go into the
> > > container is
> > > really an implementation detail that the user shouldn't have to know
> > > about.
> 
> That is the main point here:  With std::stack, there is no doubt
> which type goes into the underlying container, so the user can
> say std::stack<int, std::list<int> >  and all is well.  If, however,
> the type which should be stored in the container is an invisible
> implementation detail, my natural reaction would be "I don't need
> a type, I need a template as a parameter".  Hypothetical usage in
> the std::stack case would be  std::stack<int, std::list>.
> 
> > Ok, then how about back to the template template parameter?
> >
> > template< template<class ValueType> EdgeListS = VectorCover,
> 
> The idea was not to augment the selectors with template template
> parameters, but do away with the selectors and replace them
> with template template parameters.
> 
> Example usage for adjacency_list:
> 
> typedef adjacency_list<std::vector, std::list> Graph;
> 
> means that edges are stored in a std::vector and vertices in a
> std::list.  The declaration would be
> 
> template<template<class> class EdgeContainer,
>          template<class> class VertexContainer>
> class adjacency_list
> {  /* ... */ };
> 
> If someone wants to use a non-standard optional template
> argument, you must define a new template:
> 
> template<class T>
> struct my_set_adaptation : std::set<T, jens::less<T> >
> {
>   /* add constructors here */
> };
> 
> The disadvantage is that you have to write forwarding functions for
> the required constructors.  (This particular example doesn't make
> much sense, because the actual type for T is hidden, so I have a
> hard time writing a sensible jens::less<T>.)
> 
The problem as I see it with template template parameters for containers, is
that there isn't a fixed number of arguments. If you can only use a vector,
ggcl might as well use a vector, but if I wanted a set instead it isn't the
same number of template arguments.

(This assumes that there isn't a subset of container types for each optional
container, and that they don't interchange, ie, hash_set vs set, Where as
vector, deque, list, slist all have two parameters.)

To use template template parameters would force us to write a cover template
that takes the maximum number of arguments, which is no better than what it
already does.

The other disadvantage is that maybe some compiler which ggcl currently
supports doesn't support template template's. This of course is a tough
choice, make a bad design decision now because of lack of support and years
later we'll still be stuck with it.

I can see that Jeremy is resisting this change. I suspect for a number of
reasons. One it touches a lot of code, two, we haven't given him a
overriding reason other than the proposed change seems to fit a language
feature. And it puts more restrictions on the number of compilers which can
handle it.

My reason for pushing this change is that ggcl wants the user to specify the
container but has a nonstandard (now!) way of indicating which
std::container the user means.

Without named arguments to templates there isn't an easy way of doing this.
After all ggcl only cares about one argument to the template, the
"value_type". And that it has whatever lookup requirements are needed. And
if there needs to be an alternative way of indicating which container to
use, perhaps that should be its own .h file. (Along with a container traits
file.)

Anyone else have a better idea?

  Yours Truly,
   -Gary-

gary.powell