Ticket #1887: creating_concepts.patch

File creating_concepts.patch, 3.6 KB (added by Eric Niebler, 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"
    22    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    33
    44<html xmlns="http://www.w3.org/1999/xhtml">
     
    4747       
    4848    BOOST_CONCEPT_USAGE(InputIterator)
    4949    {
    50         X j(i);             <font color=
     50        X j(i);               <font color=
    5151"green">// require copy construction</font>
    52         same_type(*i++,v);  <font color=
    53 "green">// require postincrement-dereference returning value_type</font>
    54         X&amp; x = ++j;         <font color=
     52        value_type v = *i++;  <font color=
     53"green">// require postincrement-dereference returning convertible to value_type</font>
     54        X&amp; x = ++j;           <font color=
    5555"green">// require preincrement returning X&amp;</font>
    5656    }
    5757   
    5858 private:
    5959    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 &lt;typename T&gt;
    65     void same_type(T const&amp;, T const&amp;);
    6660};
    6761</pre>
    6862
     
    8781  <code>BOOST_CONCEPT_USAGE</code> macro to declare the function that
    8882  exercises all the concept's valid expressions. Note that at this point you
    8983  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>
    9486
    9587  <h3>Values for Usage Patterns Should Be Data Members</h3>
    9688
    97   <p>You may be wondering why we declared <code>i</code> and <code>v</code>
    98   as data members in the example above. Why didn't we simply write the
     89  <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
    9991  following?</p>
    10092  <pre>
    10193BOOST_CONCEPT_USAGE(InputIterator)
    10294{
    103     X i;                <font color=
     95    X i;                  <font color=
    10496"green">// create the values we need</font>
    105     value_type v;
    10697
    107     X j(i);             <font color=
     98    X j(i);               <font color=
    10899"green">// require copy construction</font>
    109     same_type(*i++,v);  <font color=
    110 "green">// require postincrement-dereference returning value_type</font>
    111     X&amp; x = ++j;         <font color=
     100    value_type v = *i++;  <font color=
     101"green">// require postincrement-dereference returning convertible to value_type</font>
     102    X&amp; x = ++j;           <font color=
    112103"green">// require preincrement returning X&amp;</font>
    113104}
    114105</pre>
    115106
    116107  <p>Unfortunately, that code wouldn't have worked out so well, because it
    117   unintentionally imposes the requirement that <code>X</code> and its value
    118   type are both default-constructible. On the other hand, since instances of
     108  unintentionally imposes the requirement that <code>X</code> is
     109  default-constructible. On the other hand, since instances of
    119110  the <code>InputIterator</code> template will never be constructed, the
    120111  compiler never has to check how its data members will be constructed (C++
    121112  Standard Section 14.7.1 9). For that reason you should <strong>always