Status of the concepts checking code

[Peter Schmid]

Dear Mr Edwards,

thank you very much for taking care of the checking code and fixing PR
libstdc++/2054. After updating the gcc 3.1 cvs sources today the test
case enclosed in this PR compiles fine. But if I replace the call to
lower_bound by a call to upper_bound the problem shows up again. I
propose that the checking code should be changed in the same way for
upper_bound and equal_range.

Furthermore, I would like to note that Mr Siek updated the checking
code in the boost repository. Could you please incorporate his changes
in libstdc++ if this is possible and is making sense. 

I ran many g++ and libstdc++ tests with the checking code enabled and
found only three problems, except for known coding "errors", missing
functions for random access iterators, in boost. 

First, is it possible to turn the checking code off on a per file
basis? Explicitly undefining _GLIBCPP_CONCEPT_CHECKS had no effect,
either on the gcc command line or in the source file.

Secondly, there is PR 1870 which encloses a test case that is rejected
by the checking code but I believe is legal. The code is in Josuttis'
book and in Vandevoordes book. 
Alexandre Oliva says it is illegal, though. But I do not comprehend
his reasoning, since the code indeed compiles if checking is
disabled, in contrast to his opinion that the code is illegal. 

Third, list_modifiers.cc from the libstdc++ testsuite does not
compile. According to the concept checking code a assignment operator
is required for the T class. I do not understand what this message
exactly means since with checking code disabled the file is
accepted and obviously the compiler does generate a default assignment
operator which it should not according to the message from the
checking code.  

If this operator is added the code
compiles without a problem: Except for the strange line number 132 "VERIFY(("no
exception thrown", false))" resulting in a "left-hand operand of comma
expression has no effect" warning:

Executing on host: /mnt/egcs/build/gcc/g++ -B/mnt/egcs/build/gcc/ -nostdinc++ -L/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/src -L/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -g -ffunction-sections -fdata-sections -DDEBUG_ASSERT -DLOCALEDIR="/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/po/share/locale" -nostdinc++ -I/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include -I/mnt/egcs/gcc/libstdc++-v3/libsupc++ -I/mnt/egcs/gcc/libstdc++-v3/libio -I/mnt/egcs/gcc/libstdc++-v3/include/backward -I/mnt/egcs/gcc/libstdc++-v3/testsuite /mnt/egcs/gcc/libstdc++-v3/testsuite/23_containers/list_modifiers.cc    -DDEBUG_ASSERT  -lm   -o ./list_modifiers.exe    (timeout = 300)
/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h: In
   member function `T& T::operator=(const T&)':
/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h:175:   instantiated from `void __gnu_cxx::_SGIAssignableConcept<_Tp>::__constraints() [with _Tp = T]'
/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_list.h:281:   instantiated from `std::list<T, std::allocator<T> >'
/mnt/egcs/gcc/libstdc++-v3/testsuite/23_containers/list_modifiers.cc:103:   instantiated from here
/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h:175: non-static
   const member `const int T::itsId', can't use default assignment operator
/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h:175: non-static
   const member `const bool T::willThrow', can't use default assignment 
   operator


I verified that libstdc++/2504 is indeed fixed. Could you please close
this PR. The following PRs are no longer failing: optimisation/4785,
c/3741 and c++/2295. Would you mind closing these PRs, too? 

Thank you.

Peter Schmid