forked from boostorg/concept_check
new file
[SVN r7737]
This commit is contained in:
Jeremy Siek
166
concept_checking.html
Normal file
166
concept_checking.html
Normal file
@@ -0,0 +1,166 @@
|
|||||||
|
<HTML>
|
||||||
|
<!--
|
||||||
|
-- Copyright (c) Jeremy Siek, Lie-Quan Lee, and Andrew Lumsdaine 2000
|
||||||
|
--
|
||||||
|
-- Permission to use, copy, modify, distribute and sell this software
|
||||||
|
-- and its documentation for any purpose is hereby granted without fee,
|
||||||
|
-- provided that the above copyright notice appears in all copies and
|
||||||
|
-- that both that copyright notice and this permission notice appear
|
||||||
|
-- in supporting documentation. We make no
|
||||||
|
-- representations about the suitability of this software for any
|
||||||
|
-- purpose. It is provided "as is" without express or implied warranty.
|
||||||
|
-->
|
||||||
|
<Head>
|
||||||
|
<Title>Concept Checking</Title>
|
||||||
|
<BODY BGCOLOR="#ffffff" LINK="#0000ee" TEXT="#000000" VLINK="#551a8b"
|
||||||
|
ALINK="#ff0000">
|
||||||
|
<IMG SRC="../../c++boost.gif"
|
||||||
|
ALT="C++ Boost">
|
||||||
|
|
||||||
|
<BR Clear>
|
||||||
|
|
||||||
|
<H2><A NAME="SECTION00744000000000000000"></A>
|
||||||
|
<A NAME="sec:concept-checking"></A>
|
||||||
|
<BR>
|
||||||
|
Concept Checking
|
||||||
|
</H2>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
header <a href="../../boost/pending/concept_checks.hpp"><tt>boost/concept_checks.hpp</tt></a>
|
||||||
|
|
||||||
|
<P>
|
||||||
|
The C++ language does not provide direct support for ensuring that
|
||||||
|
template arguments meet the requirements demanded of them by the
|
||||||
|
generic algorithm or template class. This means that if the user makes
|
||||||
|
an error, the resulting compiler error will point to somewhere deep
|
||||||
|
inside the implementation of the generic algorithm, giving an error
|
||||||
|
that may not be easy to match with the cause.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
We have developed a method for forcing the compiler to give better
|
||||||
|
error messages. The idea is to exercise all the requirements placed on
|
||||||
|
the template arguments at the very beginning of the generic algorithm.
|
||||||
|
We have created some macros and a methodology for how to do this.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
Suppose we wish to add concept checks to the STL <a
|
||||||
|
href="http://www.sgi.com/Technology/STL/copy.html"><TT>copy()</TT></a>
|
||||||
|
algorithm, which has the following prototype.
|
||||||
|
<PRE>
|
||||||
|
template <class InIter, class OutIter>
|
||||||
|
OutIter copy(InIter first, InIter last, OutIter result);
|
||||||
|
</PRE>
|
||||||
|
We will need to make sure the <TT>InIter</TT> is a model of <a
|
||||||
|
href="http://www.sgi.com/Technology/STL/InputIterator.html">InputIterator</a>
|
||||||
|
and that <TT>OutIter</TT> is a model of <a
|
||||||
|
href="http://www.sgi.com/Technology/STL/OutputIterator.html">OutputIterator</a>. The
|
||||||
|
first step is to create the code that will exercise the expressions
|
||||||
|
associated with each of these concepts. The following is the concept
|
||||||
|
checking class for <a
|
||||||
|
href="http://www.sgi.com/Technology/STL/OutputIterator.html">OutputIterator</a>.
|
||||||
|
The iterator objects <TT>i</TT> and <TT>j</TT> are data members of the
|
||||||
|
concept checking class which would normally require the <TT>Iter</TT>
|
||||||
|
type to be <a
|
||||||
|
href="http://www.sgi.com/Technology/STL/DefaultConstructible.html">DefaultConstructible</a>. However,
|
||||||
|
we never create instances of concept checking classes so this
|
||||||
|
requirement is not induced.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
<PRE>
|
||||||
|
template <class Iter>
|
||||||
|
struct OutputIterator {
|
||||||
|
CLASS_REQUIRES(Iter, Assignable);
|
||||||
|
void constraints() {
|
||||||
|
(void)*i; // require dereference operator
|
||||||
|
++i; // require preincrement operator
|
||||||
|
i++; // require postincrement operator
|
||||||
|
*i++ = *j; // require postincrement and assignment
|
||||||
|
}
|
||||||
|
Iter i, j;
|
||||||
|
};
|
||||||
|
</PRE>
|
||||||
|
|
||||||
|
<P>
|
||||||
|
Once the concept checking classes are complete, one simply needs to
|
||||||
|
invoke them at the beginning of the generic algorithm using our
|
||||||
|
<TT>REQUIRE</TT> macro. Here's what the STL <TT>copy()</TT> algorithm
|
||||||
|
looks like with the concept checks inserted.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
<PRE>
|
||||||
|
template <class InIter, class OutIter>
|
||||||
|
OutIter copy(InIter first, InIter last, OutIter result)
|
||||||
|
{
|
||||||
|
REQUIRE(OutIter, OutputIterator);
|
||||||
|
REQUIRE(InIter, InputIterator);
|
||||||
|
return copy_aux(first, last, result, VALUE_TYPE(first));
|
||||||
|
}
|
||||||
|
</PRE>
|
||||||
|
|
||||||
|
<P>
|
||||||
|
Looking back at the <TT>OutputIterator</TT> concept checking class, you
|
||||||
|
might wonder why we used the <TT>CLASS_REQUIRES</TT> macro instead of
|
||||||
|
just <TT>REQUIRE</TT>. The reason for this is that different tricks are
|
||||||
|
needed to force compilation of the checking code when invoking the
|
||||||
|
macro from inside a class definition instead of a function.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
For the most part, the user does not need to know how to create
|
||||||
|
concept checks and insert them in generic algorithms, however it is
|
||||||
|
good to know what they are. This will make the error messages coming
|
||||||
|
from libraries that use concept checks easier to understand. Also if
|
||||||
|
you are unsure about whether you can use a certain class with a
|
||||||
|
particular algorithm, or whether some custom-made class of your own is
|
||||||
|
compatible, a good first check is to invoke the appropriate concept
|
||||||
|
checker.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
Here's a quick example program that one could write to see if the
|
||||||
|
types <a
|
||||||
|
href="../graph/adjacency_list.html"><TT>adjacency_list</TT></a> and <a
|
||||||
|
href="../graph/edge_list.html"><TT>edge_list</TT></a> really model the
|
||||||
|
concepts they claim to.
|
||||||
|
|
||||||
|
<P>
|
||||||
|
<PRE>
|
||||||
|
#include <boost/graph/graph_concepts.hpp>
|
||||||
|
#include <boost/graph/adjacency_list.hpp>
|
||||||
|
#include <boost/graph/edge_list.hpp>
|
||||||
|
|
||||||
|
using namespace boost;
|
||||||
|
|
||||||
|
int main(int,char*[])
|
||||||
|
{
|
||||||
|
typedef adjacency_list<listS,vecS,bidirectionalS> AdjList;
|
||||||
|
REQUIRE(AdjList, VertexAndEdgeListGraph);
|
||||||
|
REQUIRE(AdjList, BidirectionalGraph);
|
||||||
|
|
||||||
|
typedef std::pair<int, int> E;
|
||||||
|
typedef edge_list<E*, E, int> EdgeList;
|
||||||
|
REQUIRE(EdgeList, EdgeListGraph);
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
</PRE>
|
||||||
|
|
||||||
|
<P>
|
||||||
|
If you create your own generic algorithms we highly encourage you to use
|
||||||
|
and publish the corresponding concept checks.
|
||||||
|
|
||||||
|
|
||||||
|
<br>
|
||||||
|
<HR>
|
||||||
|
<TABLE>
|
||||||
|
<TR valign=top>
|
||||||
|
<TD nowrap>Copyright © 2000</TD><TD>
|
||||||
|
<A HREF=http://www.boost.org/people/jeremy_siek.htm>Jeremy Siek</A>,
|
||||||
|
Univ.of Notre Dame (<A
|
||||||
|
HREF="mailto:jsiek@lsc.nd.edu">jsiek@lsc.nd.edu</A>)<br>
|
||||||
|
<A HREF=http://www.lsc.nd.edu/~llee1>Lie-Quan Lee</A>, Univ.of Notre Dame (<A HREF="mailto:llee1@lsc.nd.edu">llee1@lsc.nd.edu</A>)<br>
|
||||||
|
<A HREF=http://www.lsc.nd.edu/~lums>Andrew Lumsdaine</A>,
|
||||||
|
Univ.of Notre Dame (<A
|
||||||
|
HREF="mailto:lums@lsc.nd.edu">lums@lsc.nd.edu</A>)
|
||||||
|
</TD></TR></TABLE>
|
||||||
|
|
||||||
|
</BODY>
|
||||||
|
</HTML>
|
||||||
Reference in New Issue
Block a user