Ticket #1887: creating_concepts.patch
File creating_concepts.patch, 3.6 KB (added by , 11 years ago) |
---|
-
creating_concepts.htm
1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2 2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3 3 4 4 <html xmlns="http://www.w3.org/1999/xhtml"> … … 47 47 48 48 BOOST_CONCEPT_USAGE(InputIterator) 49 49 { 50 X j(i); <font color=50 X j(i); <font color= 51 51 "green">// require copy construction</font> 52 same_type(*i++,v); <font color=53 "green">// require postincrement-dereference returning value_type</font>54 X& x = ++j; <font color=52 value_type v = *i++; <font color= 53 "green">// require postincrement-dereference returning convertible to value_type</font> 54 X& x = ++j; <font color= 55 55 "green">// require preincrement returning X&</font> 56 56 } 57 57 58 58 private: 59 59 X i; 60 value_type v;61 62 <font color=63 "green">// Type deduction will fail unless the arguments have the same type.</font>64 template <typename T>65 void same_type(T const&, T const&);66 60 }; 67 61 </pre> 68 62 … … 87 81 <code>BOOST_CONCEPT_USAGE</code> macro to declare the function that 88 82 exercises all the concept's valid expressions. Note that at this point you 89 83 may sometimes need to be a little creative: for example, to check that 90 <code>*i++</code> returns the iterator's value type, we pass both values to 91 the <code>same_type</code> member function template, which requires both 92 arguments to have the same type, modulo references and cv-qualification. 93 It's an imperfect check, but it's better than nothing.</p> 84 <code>*i++</code> returns something convertible to the iterator's value type, 85 we use it to initialize a variable of type <code>value_type</code>.</p> 94 86 95 87 <h3>Values for Usage Patterns Should Be Data Members</h3> 96 88 97 <p>You may be wondering why we declared <code>i</code> and <code>v</code>98 as data membersin the example above. Why didn't we simply write the89 <p>You may be wondering why we declared <code>i</code> 90 as a data member in the example above. Why didn't we simply write the 99 91 following?</p> 100 92 <pre> 101 93 BOOST_CONCEPT_USAGE(InputIterator) 102 94 { 103 X i; <font color=95 X i; <font color= 104 96 "green">// create the values we need</font> 105 value_type v;106 97 107 X j(i); <font color=98 X j(i); <font color= 108 99 "green">// require copy construction</font> 109 same_type(*i++,v); <font color=110 "green">// require postincrement-dereference returning value_type</font>111 X& x = ++j; <font color=100 value_type v = *i++; <font color= 101 "green">// require postincrement-dereference returning convertible to value_type</font> 102 X& x = ++j; <font color= 112 103 "green">// require preincrement returning X&</font> 113 104 } 114 105 </pre> 115 106 116 107 <p>Unfortunately, that code wouldn't have worked out so well, because it 117 unintentionally imposes the requirement that <code>X</code> and its value118 type are bothdefault-constructible. On the other hand, since instances of108 unintentionally imposes the requirement that <code>X</code> is 109 default-constructible. On the other hand, since instances of 119 110 the <code>InputIterator</code> template will never be constructed, the 120 111 compiler never has to check how its data members will be constructed (C++ 121 112 Standard Section 14.7.1 9). For that reason you should <strong>always