title: The use of size_t in an array iterator
body: <p>I have learned recently that size_t was introduced to help future-proof code against native bit count increases and increases in available memory. The specific use definition seems to be on the storing of the size of something, generally an array.</p>
  
  <p>I now must wonder how far this future proofing should be taken. Surely it is pointless to have an array length defined using the future-proof and appropriately sized size_t if the very next task of iterating over the array uses say an <code>unsigned int</code> as the index array:</p>
  
  <pre><code>void (double* vector, size_t vectorLength) {
      for (unsigned int i = 0; i &lt; vectorLength; i++) {
          //...
      }
  }
  </code></pre>
  
  <p>In fact in this case I might expect the syntax strictly should up-convert the unsigned int to a size_t for the relation operator.</p>
  
  <p>Does this imply the iterator variable <code>i</code> should simply be a <code>size_t</code>?</p>
  
  <p>Does this imply that any integer in any program must become functionally identified as to whether it will ever be used as an array index?</p>
  
  <p>Does it imply any code using logic that develops the index programmatically should then create a new result value of type size_t, particularly if the logic relies on potentially signed integer values? i.e.</p>
  
  <pre><code>double foo[100];
  //...
  int a = 4;
  int b = -10;
  int c = 50;
  
  int index = a + b + c;
  double d = foo[(size_t)index];
  </code></pre>
  
  <p>Surely though since my code logic creates a fixed bound, up-converting to the size_t provides no additional protection.</p>