Re: [boost] issues with concept checks

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-01-20 15:02:49

Hi Greg,

Thanks for the email.

On Sat, 20 Jan 2001, Gregory Seidman wrote:

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

Yes, I'm to blame for the SGI STL concept checks, and the boost checks ;)

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

According to 24.1.2 of the standard, an OutputIterator is required to be
Assignable.

This means that a C++ vendor's version of std::copy could use operator=,
and that for your code to be portable, you need to provide the operator=.
It's better to find out this kind of thing sooner than later.

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

Yes, I'm aware of this problem. The problem is partially my fault, and
partially a problem in the standard. There are people working on the
solution for this, but it is non-trivial to fix.

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

Yes, I certainly agree that overly-constraining concept checking is a bad
thing.

I'd encourage you not to think of concept checking itself as a bad thing.
It's like a messenger carrying bad news... don't shoot the messenger! The
message is that there are concepts defined in the standard and elsewhere
that have mistakes in them: over-constraining, under-constraining, too
vague, etc. In the passed, we could ignore the problems because they
didn't affect us in a painful way (compiler errors). With concept checks
they do affect us, and we will need to fix them. In the end, we will have
much better concept descriptions because of this process.

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek_at_[hidden]
 Univ. of Notre Dame         work phone: [phone]
----------------------------------------------------------------------