1 | <HTML> |
---|
2 | <!-- |
---|
3 | -- Copyright (c) Jeremy Siek and Andrew Lumsdaine 2000 |
---|
4 | -- |
---|
5 | -- Permission to use, copy, modify, distribute and sell this software |
---|
6 | -- and its documentation for any purpose is hereby granted without fee, |
---|
7 | -- provided that the above copyright notice appears in all copies and |
---|
8 | -- that both that copyright notice and this permission notice appear |
---|
9 | -- in supporting documentation. We make no |
---|
10 | -- representations about the suitability of this software for any |
---|
11 | -- purpose. It is provided "as is" without express or implied warranty. |
---|
12 | --> |
---|
13 | <Head> |
---|
14 | <Title>Concept Check Library</Title> |
---|
15 | </head> |
---|
16 | |
---|
17 | <BODY BGCOLOR="#ffffff" LINK="#0000ee" TEXT="#000000" VLINK="#551a8b" |
---|
18 | ALINK="#ff0000"> |
---|
19 | <IMG SRC="../../boost.png" |
---|
20 | ALT="C++ Boost" width="277" height="86"> |
---|
21 | |
---|
22 | <BR Clear> |
---|
23 | |
---|
24 | <H1>The Boost Concept Check Library (BCCL)</H1> |
---|
25 | |
---|
26 | <h2> |
---|
27 | <A NAME="sec:concept-checking"></A> |
---|
28 | header <a href="../../boost/concept_check.hpp"> |
---|
29 | <tt>boost/concept_check.hpp</tt></a> |
---|
30 | <br>and <a href="../../boost/concept_archetype.hpp"> |
---|
31 | <tt>boost/concept_archetype.hpp</tt></a> |
---|
32 | </h2> |
---|
33 | |
---|
34 | <p> |
---|
35 | Generic programming in C++ is characterized by the use of template |
---|
36 | parameters to represent abstract data types (or ``concepts''). |
---|
37 | However, the C++ language itself does not provide a mechanism for the |
---|
38 | writer of a class or function template to explicitly state what |
---|
39 | concept the user-supplied template argument should model (or conform |
---|
40 | to). The common practice is to name the template parameter after the |
---|
41 | required concept as a hint to the user and to state the concept |
---|
42 | requirements in the documentation. However, often times the |
---|
43 | requirements are vague, incorrect, or nonexistent, which is quite a |
---|
44 | problem for the user, since he or she will not know exactly what kind |
---|
45 | of input is expected by the template. Furthermore, the following |
---|
46 | problems occur: |
---|
47 | |
---|
48 | <ul> |
---|
49 | <li>Compiler error messages resulting from incorrect template |
---|
50 | arguments can be particularly difficult to decipher. Often times |
---|
51 | the error does not point to the location of the template |
---|
52 | call-site, but instead exposes the internals of the template, which |
---|
53 | the user should never have to see.</li> |
---|
54 | |
---|
55 | <li>The documented concept requirements may not fully <i>cover</i> |
---|
56 | the template, meaning the user could get a compiler error even |
---|
57 | though the supplied template arguments meet the documented |
---|
58 | requirements.</li> |
---|
59 | |
---|
60 | <li>The documented concept requirements may be too stringent, |
---|
61 | requiring more than is really needed by the template.</li> |
---|
62 | |
---|
63 | <li>The requirements are not explicitly stated in the code, which |
---|
64 | makes the code harder to understand. Also, the code may |
---|
65 | get out-of-sync with the documented requirements.</li> |
---|
66 | </ul> |
---|
67 | |
---|
68 | The Boost Concept Checking Library provides: |
---|
69 | |
---|
70 | <ul> |
---|
71 | <li>A mechanism for inserting compile-time checks of template |
---|
72 | parameters.</li> |
---|
73 | |
---|
74 | <li>A framework for specifying concept requirements though concept |
---|
75 | checking classes.</li> |
---|
76 | |
---|
77 | <li>A mechanism for verifying that concept requirements cover the template.</li> |
---|
78 | |
---|
79 | <li>A suite of concept checking classes and archetype classes that |
---|
80 | match the concept requirements in the C++ Standard Library.</li> |
---|
81 | </ul> |
---|
82 | |
---|
83 | The mechanisms use standard C++ and introduce no run-time |
---|
84 | overhead. The main cost of using the mechanism is in compile-time. |
---|
85 | |
---|
86 | <p> |
---|
87 | Any programmer writing class or function templates ought to make |
---|
88 | concept checking a normal part of their code writing routine. A |
---|
89 | concept check should be inserted for each template parameter in a |
---|
90 | component's public interface. If the concept is one of the ones from |
---|
91 | the Standard Library, then simply use the matching concept checking |
---|
92 | class in the BCCL. If not, then write a new concept checking class - |
---|
93 | after all, they are typically only a few lines long. For new concepts, |
---|
94 | a matching archetype class should also be created, which is a minimal |
---|
95 | skeleton-implementation of the concept |
---|
96 | |
---|
97 | <p> |
---|
98 | The documentation is organized into the following sections. |
---|
99 | |
---|
100 | <OL> |
---|
101 | <LI><a href="#introduction">Introduction</a></LI> |
---|
102 | <LI><a href="#motivating-example">Motivating Example</a></LI> |
---|
103 | <LI><a href="#history">History</a></LI> |
---|
104 | <LI><a href="#publications">Publications</a></LI> |
---|
105 | <LI><a href="#acknowledgements">Acknowledgements</a></LI> |
---|
106 | <LI><a href="./using_concept_check.htm">Using Concept Checks</a></LI> |
---|
107 | <LI><a href="creating_concepts.htm">Creating Concept Checking Classes</a></LI> |
---|
108 | <LI><a href="./concept_covering.htm">Concept Covering and Archetypes</a></LI> |
---|
109 | <LI><a href="./prog_with_concepts.htm" ">Programming With Concepts</a></LI> |
---|
110 | <LI><a href="./implementation.htm">Implementation</a></LI> |
---|
111 | <LI><a href="./reference.htm">Reference</a></LI> |
---|
112 | </OL> |
---|
113 | |
---|
114 | <p> |
---|
115 | <a href="../../people/jeremy_siek.htm">Jeremy Siek</a> contributed |
---|
116 | this library. <a href="../../people/beman_dawes.html">Beman Dawes</a> |
---|
117 | managed the formal review. |
---|
118 | |
---|
119 | <h2><a name="introduction">Introduction</a></h2> |
---|
120 | |
---|
121 | A <i>concept</i> is a set of requirements (valid expressions, |
---|
122 | associated types, semantic invariants, complexity guarantees, etc.) |
---|
123 | that a type must fulfill to be correctly used as arguments in a call |
---|
124 | to a generic algorithm. In C++, concepts are represented by formal |
---|
125 | template parameters to function templates (generic algorithms). |
---|
126 | However, C++ has no explicit mechanism for representing concepts --- |
---|
127 | template parameters are merely placeholders. By convention, these |
---|
128 | parameters are given names corresponding to the concept that is |
---|
129 | required, but a C++ compiler does not enforce compliance to the |
---|
130 | concept when the template parameter is bound to an actual type. |
---|
131 | |
---|
132 | <p> |
---|
133 | Naturally, if a generic algorithm is invoked with a type that does not |
---|
134 | fulfill at least the syntactic requirements of the concept, a |
---|
135 | compile-time error will occur. However, this error will not <i>per |
---|
136 | se</i> reflect the fact that the type did not meet all of the |
---|
137 | requirements of the concept. Rather, the error may occur deep inside |
---|
138 | the instantiation hierarchy at the point where an expression is not |
---|
139 | valid for the type, or where a presumed associated type is not |
---|
140 | available. The resulting error messages are largely uninformative and |
---|
141 | basically impenetrable. |
---|
142 | |
---|
143 | <p> |
---|
144 | What is required is a mechanism for enforcing ``concept safety'' at |
---|
145 | (or close to) the point of instantiation. The Boost Concept Checking |
---|
146 | Library uses some standard C++ constructs to enforce early concept |
---|
147 | compliance and that provides more informative error messages upon |
---|
148 | non-compliance. |
---|
149 | |
---|
150 | <p> |
---|
151 | Note that this technique only addresses the syntactic |
---|
152 | requirements of concepts (the valid expressions and associated types). |
---|
153 | We do not address the semantic invariants or complexity guarantees, |
---|
154 | which are also part of concept requirements.. |
---|
155 | |
---|
156 | <h2><a name="motivating-example">Motivating Example</a></h2> |
---|
157 | |
---|
158 | We present a simple example to illustrate incorrect usage of a |
---|
159 | template library and the resulting error messages. In the code below, |
---|
160 | the generic <tt>std::stable_sort()</tt> algorithm from the Standard |
---|
161 | Template Library (STL)[<a |
---|
162 | href="bibliography.htm#austern99:_gener_progr_stl">3</a>, <a |
---|
163 | href="bibliography.htm#IB-H965502">4</a>,<a |
---|
164 | href="bibliography.htm#stepa.lee-1994:the.s:TR">5</a>] is applied to |
---|
165 | a linked list. |
---|
166 | |
---|
167 | <pre> |
---|
168 | <a href="./bad_error_eg.cpp">bad_error_eg.cpp</a>: |
---|
169 | 1 #include <list> |
---|
170 | 2 #include <algorithm> |
---|
171 | 3 |
---|
172 | 4 int main(int, char*[]) { |
---|
173 | 5 std::list<int> v; |
---|
174 | 6 std::stable_sort(v.begin(), v.end()); |
---|
175 | 7 return 0; |
---|
176 | 8 } |
---|
177 | </pre> |
---|
178 | |
---|
179 | Here, the |
---|
180 | <tt>std::stable_sort()</tt> algorithm is prototyped as follows: |
---|
181 | <pre> |
---|
182 | template <class RandomAccessIterator> |
---|
183 | void stable_sort(RandomAccessIterator first, RandomAccessIterator last); |
---|
184 | </pre> |
---|
185 | |
---|
186 | Attempting to compile this code with Gnu C++ produces the following |
---|
187 | compiler error. The output from other compilers is listed in the |
---|
188 | Appendix. |
---|
189 | |
---|
190 | <pre> |
---|
191 | stl_algo.h: In function `void __merge_sort_loop<_List_iterator |
---|
192 | <int,int &,int *>, int *, int>(_List_iterator<int,int &,int *>, |
---|
193 | _List_iterator<int,int &,int *>, int *, int)': |
---|
194 | stl_algo.h:1448: instantiated from `__merge_sort_with_buffer |
---|
195 | <_List_iterator<int,int &,int *>, int *, int>( |
---|
196 | _List_iterator<int,int &,int *>, _List_iterator<int,int &,int *>, |
---|
197 | int *, int *)' |
---|
198 | stl_algo.h:1485: instantiated from `__stable_sort_adaptive< |
---|
199 | _List_iterator<int,int &,int *>, int *, int>(_List_iterator |
---|
200 | <int,int &,int *>, _List_iterator<int,int &,int *>, int *, int)' |
---|
201 | stl_algo.h:1524: instantiated from here |
---|
202 | stl_algo.h:1377: no match for `_List_iterator<int,int &,int *> & - |
---|
203 | _List_iterator<int,int &,int *> &' |
---|
204 | </pre> |
---|
205 | |
---|
206 | In this case, the fundamental error is that |
---|
207 | <tt>std:list::iterator</tt> does not model the concept of <a |
---|
208 | href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> |
---|
209 | RandomAccessIterator</a>. The list iterator is only bidirectional, not |
---|
210 | fully random access (as would be a vector iterator). Unfortunately, |
---|
211 | there is nothing in the error message to indicate this to the user. |
---|
212 | |
---|
213 | <p> |
---|
214 | To a C++ programmer having enough experience with template libraries |
---|
215 | the error may be obvious. However, for the uninitiated, there are several |
---|
216 | reasons why this message would be hard to understand. |
---|
217 | |
---|
218 | <OL> |
---|
219 | <LI> The location of the error, line 6 of <tt>bad_error_eg.cpp</tt> |
---|
220 | is not pointed to by the error message, despite the fact that Gnu C++ |
---|
221 | prints up to 4 levels deep in the instantiation stack. |
---|
222 | <LI> There is no textual correlation between the error message and the |
---|
223 | documented requirements for <tt>std::stable_sort()</tt> and for |
---|
224 | <a |
---|
225 | href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> |
---|
226 | RandomAccessIterator</a>. |
---|
227 | <LI> The error message is overly long, listing functions internal |
---|
228 | to the STL that the user does not (and should not!) know or care |
---|
229 | about. |
---|
230 | <LI> With so many internal library functions listed in the error |
---|
231 | message, the programmer could easily infer that the error is due |
---|
232 | to the library, rather than to his or her own code. |
---|
233 | </OL> |
---|
234 | |
---|
235 | The following is an example of what we might expect from a more |
---|
236 | informative message (and is in fact what the Boost Concept Checking |
---|
237 | Library produces): |
---|
238 | |
---|
239 | <pre> |
---|
240 | boost/concept_check.hpp: In method `void LessThanComparableConcept |
---|
241 | <_List_iterator<int,int &,int *> >::constraints()': |
---|
242 | boost/concept_check.hpp:334: instantiated from `RandomAccessIteratorConcept |
---|
243 | <_List_iterator<int,int &,int *> >::constraints()' |
---|
244 | bad_error_eg.cpp:6: instantiated from `stable_sort<_List_iterator |
---|
245 | <int,int &,int *> >(_List_iterator<int,int &,int *>, |
---|
246 | _List_iterator<int,int &,int *>)' |
---|
247 | boost/concept_check.hpp:209: no match for `_List_iterator<int,int &,int *> & |
---|
248 | < _List_iterator<int,int &,int *> &' |
---|
249 | </pre> |
---|
250 | |
---|
251 | This message rectifies several of the shortcomings of the standard |
---|
252 | error messages. |
---|
253 | |
---|
254 | <UL> |
---|
255 | <LI> The location of the error, <tt>bad_error_eg.cpp:6</tt> is |
---|
256 | specified in the error message. |
---|
257 | <LI> The message refers explicitly to concepts that the user can look |
---|
258 | up in the STL documentation (<a |
---|
259 | href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> |
---|
260 | RandomAccessIterator</a>). |
---|
261 | <LI> The error message is now much shorter and does not reveal |
---|
262 | internal STL functions. |
---|
263 | <LI> The presence of <tt>concept_check.hpp</tt> and |
---|
264 | <tt>constraints()</tt> in the error message alerts the user to the |
---|
265 | fact that the error lies in the user code and not in the library |
---|
266 | implementation. |
---|
267 | </UL> |
---|
268 | |
---|
269 | <h2><a name="history">History</a></h2> |
---|
270 | |
---|
271 | An earlier version of this concept checking system was developed by |
---|
272 | the author while working at SGI in their C++ compiler and library |
---|
273 | group. The earlier version is now part of the SGI STL distribution. The |
---|
274 | boost concept checking library differs from the concept checking in |
---|
275 | the SGI STL in that the definition of concept checking classes has |
---|
276 | been greatly simplified, at the price of less helpful verbiage in the |
---|
277 | error messages. |
---|
278 | |
---|
279 | <h2><a name="publications">Publications</a></h2> |
---|
280 | |
---|
281 | <ul> |
---|
282 | <li><a href="http://www.oonumerics.org/tmpw00/"> |
---|
283 | C++ Template Workshop 2000</a>, Concept Checking</li> |
---|
284 | </ul> |
---|
285 | |
---|
286 | <h2><a name="acknowledgements">Acknowledgements</a></h2> |
---|
287 | |
---|
288 | The idea to use function pointers to cause instantiation is due to |
---|
289 | Alexander Stepanov. I am not sure of the origin of the idea to use |
---|
290 | expressions to do up-front checking of templates, but it did appear in |
---|
291 | D&E[ |
---|
292 | <a href="bibliography.htm#stroustrup94:_design_evolution">2</a>]. |
---|
293 | Thanks to Matt Austern for his excellent documentation and |
---|
294 | organization of the STL concepts, upon which these concept checks |
---|
295 | are based. Thanks to Boost members for helpful comments and |
---|
296 | reviews. |
---|
297 | |
---|
298 | |
---|
299 | <p> |
---|
300 | <a href="./using_concept_check.htm">Next: Using Concept Checks</a> |
---|
301 | |
---|
302 | <br> |
---|
303 | <HR> |
---|
304 | <TABLE> |
---|
305 | <TR valign=top> |
---|
306 | <TD nowrap>Copyright © 2000</TD><TD> |
---|
307 | <A HREF="../../people/jeremy_siek.htm">Jeremy Siek</A>(<A |
---|
308 | HREF="mailto:jsiek@osl.iu.edu">jsiek@osl.iu.edu</A>) |
---|
309 | Andrew Lumsdaine</A>(<A HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu</A>) |
---|
310 | </TD></TR></TABLE> |
---|
311 | |
---|
312 | </BODY> |
---|
313 | </HTML> |
---|