Boost logo

Boost :

From: Gregory Seidman (gseidman_at_[hidden])
Date: 2001-01-20 11:17:02


I haven't actually been using Boost yet, partly because I am too lazy to
install it and partly because the documentation isn't as complete and
centrally located as the SGI STL docs. Nonetheless, I discovered that the
person in charge of maintaining gcc/g++ on our system has installed a newer
SGI STL which includes concept checking. In looking at the concept_checks.h
file in which various compile errors were occurring, I found a "Copyright
Jeremy Siek" line, so I figure it has to be at least related to the concept
checks being worked on for boost.

The issues I've had are simply over-eager or downright wrong concept checks
being applied to STL functions. To wit, std::copy insists that its
OutputIterator argument satisfy the OutputIterator concept -- fine in and
of itself -- but somehow the OutputIterator concept includes a requirement
that a copying op= (i.e. OutputIterator &operator=(const OutputIterator
&rhs)) be defined. This is, as far as I can tell, wrong. It needs a copy
constructor, but I don't think it should need a copying op=.

Also, std::lower_bound requires that its value (or LessThanComparable,
depending on which overloaded version one uses) argument, of arbitrary type
T, be the same type as *ForwardIterator; this seems logical, until you
realize that one can define either an op< or a StrictWeakOrdering functor
which takes heterogeneous arguments and expect it to work just fine.

These are just the two examples I have run into in the past day and they
are with a version of concept checking apparently distributed with the SGI
STL as of June or something, so they may or may not apply to the concept
checking code currently in/being considered for Boost. Nonetheless, this
sort of overly-constraining concept checking reduces the usefulness of the
templated code rather than increasing the usefulness of error messages. I
have taken to deliberately including the concept_checks.h file at the
beginning of my source files so that the no-ops defined for non-conforming
compilers are used and, therefore, concept checking is effectively off for
my code. I shouldn't have to do that and, more importantly, I shouldn't
want to.

--Greg


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk