This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: testing techniques for verifying includes in std:: namespace
On Feb 15, 2007, at 12:09 PM, Benjamin Kosnik wrote:
Currently, these tests don't exist, per se. Many containers and
structures have an instantiation test, which will test as a
side-effect that things are in the correct namespace. I am
thinking of
formalizing this for all containers, making them consistent, and
adopting the TR1 random idea of a "requirements" subdirectory for the
tests which do:
1) base class check
2) typedef check
3) required default arguments
4) explicit instantiations (which will now be instantiate.cc)
As a side benefit, this looks like the likely landing place for
concept checking and invariant checking.
I don't see any systematic testing for this in the latest concept
gcc patches. Thoughts Doug?
Concept checking, at least in the sense that we do it for C++03,
doesn't make a lot of sense in ConceptGCC. There are typically three
parts to concept checking:
- The "archetypes" part, which tests that an algorithm does not try
to use any operations on its input types that aren't stated in the
concept requirements. For example, this would detect a "for (; first
< last; ++first)" error in an algorithm that is meant to take input
iterators. This kind of checking is unnecessary in ConceptGCC,
because the compiler itself will diagnose the error when the template
is parsed.
- The "concept checks" part, which tests that the user has provided
types that meet the minimum stated requirements of the algorithm. For
example, this would detect an attempt to use adjacent_find on an
input iterator. This kind of checking is unnecessary in ConceptGCC,
because the compiler checks that the user-provided types meet the
stated requirements of the algorithm before the algorithm is
instantiated.
- The other "concept checks" part, which tests that the data
structures provided by a library meet the requirements of its
concepts. For example, this would check that vector<int> is actually
a model of the Sequence concept. This kind of checking is unnecessary
in ConceptGCC, because the library contains "concept maps" stating
that vector<T> is a model of Sequence, and the compiler checks the
correctness of concept maps when they are defined.
Unless there are other concept-related checks that I'm not thinking
of, concept checking doesn't really have a place in a concept-enabled
library. We've provided language features that do all of that
checking for us, automatically, without the need for the techniques
used in today's concept checkers. In ConceptGCC, I've just stripped
out all of the existing concept-checking code.
Cheers,
Doug