Both of you mentioned that the return types are specified in
the STL documentation. The STL documentation shows that for a
vector that begin() returns an 'iterator'.
iterator begin() Container Returns an iterator pointing to the
beginning of the vector.
From what I understand, this would be a typedef'd class inside
the vector definition.
Might be. Could be anything, really, that results in a
vector<xxx>::iterator being a type which conforms to the concept
of a random access iterator. (In many early implementations of
the STL, it was a typedef to a pointer.)
The answer is shamelessly dodgy: it depends. As far as the
standard containers go, the standard does not specify exactly
what an iterator is.
Of course not. All it does is specify how to get one, how to
declare one, and what you can do with it. Anything more would
be over-specification.
What it does say is that, for example, the class vector has to
at least have a public typedef that looks like the following,
where the token unspecified is a type that can be whatever the
implementation wants:
// In <vector>, within the declaration of vector
typedef unspecified iterator;
typedef unspecified const_iterator;
" -http://
www.oreillynet.com/pub/a/network/2005/10/18/what-is-iterator-i....
You've raised an interesting point. I don't think that the
intent is to require a typedef. Certainly in the requirements
section, all that is required is that container::iterator name a
type. Of hand, I would expect a nested class to be legal as
well.
So, from what the STL documentation is telling me, begin()
will return a class that satisfies the 'iterator' concept.
However, the STL documentation does not mention an iterator
concept (it does mention some other iterator concepts, such as
trivial iterator, input iterator, etc..)
The very first line about std::vector in the standard is "A
vector is a kind of sequence that supports random access
iterators." So the iterator type most meet the requirements of
a random access iterator. Requirements which are spelled out in
detail in §24.1.5 (called not surprisingly "Random access
iterators").
So, how do I know the interface that the returned object from
begin() will have? Jossutti's 'C++ standard library' states
that a vector returns a random access iterator, but I haven't
been able to find reference to this in the documentation.
Victor, as a side note, doesn't leaving the implementation of
iterators up to a specific implementor create an opportunity
to produce unportable code?
Of course. In practice, some implementations still use a
typedef to a pointer, others use a class, and there are things
that will work with one, and not with the other (due to the fact
that in one case, the ++ operator is a built-in operator, and in
the other, it is a member function). On the other hand, it
allows the implementation to be tuned to its user requirements.
(With a poor compiler, the pointer will probably be faster than
the class; the class will allow debugging implementations which
catch more errors, however.) If you respect the contract, your
code will be portable, however. If you don't, the standard has
decided that it will be undefined behavior; no error message is
required. And code which "happens to work" despite undefined
behavior is not portable. (This is no different that code which
depends on function arguments being evaluated in a specific
order.)
As mentioned in another thread that you have contributed to,
titled 'returning an iterator 'concept'', the actual class
behind the typedef'ed iterator could be anything that at the
least satisfies the iterator concept. If it in fact provides
more than that concept in implementation A, and a client uses
that extra functionality, then wouldn't the client code not
necessarily be portable to implementation B?
Yup. It's part of the basic philosophy of C++. If on my
machine, an int is 32 bits, and my code depends on this, then it
won't be portable to machines where ints are only 16 bits. If
on my machine, function arguments are evaluated from left to
right, and my code depends on this, then it won't be portable to
systems where this is not the case. (There is a difference, of
course. In the first case, I can count on the size of an int
being the same within a given implementation: the
implementation, and usually the platform, documents and
guarantees a specific size. So my code is guaranteed to work
for the implementation in question. In the case of order of
evaluation of arguments, the implementation doesn't guarantee
anything, and my code just happens to work, and may break with a
different set of optimization options. As far as I know,
variations in the implementation of iterators all fall into the
later category at present.)
