From: Rob Stewart (stewart_at_[hidden])
Date: 2003-10-27 15:23:39
From: David Abrahams <dave_at_[hidden]>
> Rob Stewart <stewart_at_[hidden]> writes:
> > A substring is not a structural element of the container. A
> > container is, by definition, composed of elements. A substring
> > is a semantic notion temporarily associated with a portion of a
> > container. Thus, the former should be denoted using the usual
> > C/C++ indexing notation. The latter, OTOH, should be denoted
> > using the vernacular: we use ordinals to refer to things like
> > substrings. That means numbering from one for substrings.
> >> What would then denote find_nth( s, XX, 0 )? Should it throw an exception?
> > Sure.
> I don't get it. The first element of a sequence is s. Why
> shouldn't the first matching substring be find_nth(s, XX, 0)?
Because s isn't the 0th element; it's the first. As I said,
we use ordinals to refer to things like this. Addressing an
element uses an index, and indexes start at zero. "nth"
explicitly refers to ordinals, and there's no 0th; you start with
1st, so find_nth() should reasonably start numbering from one.
> You can think of find_nth as indexing into a view onto the matching
> substrings of s if you want.
OK, but where's the view object with a subscript operator to
which I can supply 0 as an index?
> I imagine most C++ programmers will have the same trouble
> understanding why the first should be 1 in this case.
You have a good imagination! ;-)
> Finally, interfaces which allow values to be passed at compile-time
> which are *always* illegal at runtime are a bad idea. That's
> especially true for an unsigned zero, and especially in this case
> which is clearly confusable.
I find "0th" confusing and that's what find_nth(s, XX, 0) is
asking for. That should always fail, IMO, since there is no such
thing as a 0th entity.
Why not just specialize find_nth() for 0 so it does not compile?
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk