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

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-08-31 15:52:10

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

>   Jens? Is any of this what you
> were originally thinking?

I had not been thinking that far, but in that direction.

Jens Maurer