title: Why is reverse_iterator::base offset?
body: <pre><code>      +-- v.begin()           +-- v.end()
        |                       |
        v                       v
      +---+---+---+---+---+---+ - +
      | o | o | o | o | o | o | x |
      +---+---+---+---+---+---+ - +
  
  + - +---+---+---+---+---+---+
  | x | o | o | o | o | o | o |
  + - +---+---+---+---+---+---+
    ^                       ^
    |                       |
    +-- v.rend()            +-- v.rbegin()
  </code></pre>
  <p>(ASCII copied, and edited, from <a href="https://stackoverflow.com/a/12587633/5825294">this answer</a>, which is actually prompted me to ask the present question.)</p>
  <p>I do see the advantage of having that <code>&amp;*rit == &amp;*(rit.base() - 1)</code>, because this way I can take the <code>rit.base()</code> for any reverse iterator <code>rit</code> and I'll always get a valid iterator.</p>
  <p>But at the same time</p>
  <ul>
  <li>I cannot dereference <code>v.rbegin().base()</code>; I have to remember subtracting 1 first, <code>*(v.rbegin().base() - 1)</code>,</li>
  <li>and I cannot dereference <code>v.rend().base() - 1</code> exactly because I can't dereference <code>v.rend() </code>.</li>
  </ul>
  <p>What if the design was that <code>&amp;*rit == &amp;*rit.base()</code>?</p>
  <ul>
  <li>We couldn't call <code>v.rend().base()</code>, true, but that simply corresponds to not being able to dereference <code>v.rend().base() - 1</code> in the current design;</li>
  <li>We wouldn't be able to get <code>v.end()</code> directly from a reverse iterator, not even the closest one, <code>b.rbegin()</code>, but that simply to the <code>- 1</code> we have to add to <code>rit.base()</code> in the current design to get a forward iterator to the same element as the reverse.</li>
  </ul>
  <p>What I mean is that it seems to me that whether the design decision was that <code>&amp;*rit == &amp;*(rit.base() - 1)</code> (as it was) or that <code>&amp;*rit == &amp;*rit.base()</code>, we'd have had the same amount of convenience</p>
  <ul>
  <li><code>rit.base()</code> is always ok in the actual design,</li>
  <li><code>- 1</code> is not generally needed in the alternative design</li>
  </ul>
  <p>and inconvenience</p>
  <ul>
  <li>can't dereference all valid <code>rit.base()</code>s in the actual design,</li>
  <li>need to <code>+1</code> <code>v.rbegin()</code> to get <code>v.end()</code> in the alternative design,</li>
  </ul>
  <p>just in opposite situations.</p>
  <p>So my question is: is there a definitive advantage in making the choice that has indeed been made? Or was it just a flipped coin?</p>
  <hr />
  <p>I see that there's no valid iterator before the first element, but that's my point. When reverse iterators were introduced, what would have been wrong with making <code>std::prev(v.begin())</code> a valid, non-dereferenceable iterator just like <code>v.end()</code>?</p>
  <hr />
  <p>In hindsight, I do see one unquestionable advantage.</p>
  <p>I didn't see the advantage of <code>v.rbegin().base() == v.end()</code>/<code>v.rend().base() == v.begin()</code> because why would I want to create <code>v.end()</code>/<code>v.begin()</code> from their reverse counterparts?</p>
  <p>But if I have two reverse iterators <code>rit1</code> and <code>rit2</code> that define the range <code>(rit1, rit2]</code>, then taking <code>it1 = rit1.base()</code> and <code>it2 = rit2.base()</code> allows to refer easily to the same range of elements in the opposite direction, <code>[it1, it2)</code>.</p>
  <p>Long story short: _I should have read §9.4.1 from <em>The C++ Standarl Library - 2nd ed.</em> first.</p>