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

From: jsiek_at_[hidden]
Date: 2000-09-01 13:58:25

Beman Dawes writes:
 > jsiek_at_[hidden] wrote:
 > 
 >  >I'm getting ready to reorganize the file structure of GGCL
 >  >to fit into boost.
 > 
 > You might want to relax over the weekend; the formal review period doesn't 
 > end until Sunday, IIRC:-)  Give the Review Manager (Dave) a chance to 
 > comment on issues raised during the review.

Don't worry, there's a big Notre Dame (american) football game
tomorrow, so I'll be relaxing :)

 >  > We have two options:
 >  >
 >  >1. move everything from ggcl/ to boost/
 >  >2. move everything from ggcl/ to boost/graph/
 >  >
 >  >I think 1) would be most convenient, but there are a awful lot of
 >  >files. 2) would keep boost/ from getting as cluttered.
 > 
 > There are just too many files. I strongly vote for putting them in 
 > boost/graph.
 >
 > ...
 > 
 > Hum... Some of these are of general interest (meta.hpp, etc.) or are 
 > special in some other way (limits.hpp).
 > 
 > We need to talk more about headers with lots of potential use outside the 
 > context of ggcl. Such headers should live in boost, rather than 
 > boost/graphs. They should be documented separately, too.  For generally 
 > useful components, I'd like the docs in HTML.  They should really have one 
 > or more separate formal reviews, too.  Ideas?

Right, we should probably have a separate formal review for each of the
following files:

concept_checks.hpp
container_traits.hpp
fibonacci_heap.hpp
mutable_queue.hpp
meta.hpp
limits.hpp             (well, maybe this one doesn't deserve review)
iterator_adaptors.hpp  (forgot to list this one before)

I'm wondering if we should go ahead an add these into boost when GGCL
is added (since GGCL depends on them), but flag them as "tentative"
until they pass review (perhaps placing them in the detail
namespace). The dependence on these files is at the implementation
level, so any changes during review won't affect the public interface
of GGCL.

Cheers,

Jeremy