vector<T>::iterator

Thomas Kunert kunert@physik.tu-dresden.de
Thu Jul 31 08:17:00 GMT 2003


Phil Edwards wrote:
> 
> Somewhere between slim and none, yes.
> 

I take this as different from zero.

The main idea of the STL was to simplify the programming of
certain tasks with a very small performance penalty,
which of course depends heavily on the optimization
abilities of the compiler.
So why do you add some additional, unnecessary burden on the
compiler which buys you nothing in terms of code cleanliness and
IMO very little in terms of safety?

One problem for me at least is, the current state of affairs
makes vector::iterator useless in many circumstances. Say
you are given some vector

vector<double> v;

and you want to apply some algorithm, e.g. sort, on it.
The easiest code to do that is

sort( v.begin(), v.end() );

but given the current definition of the iterator paired with
unreliable optimization in the compiler this code is simply
irresponsible and deserves forbidden. What you have to write
is of course

sort( &*v.begin(), &*v.end() );

because this is almost as simple and possibly much faster. And,
most importantly, there is _NO LOSS OF TYPE SAFETY_ here. This
argument holds for almost all uses of iterators: Why should one
bet the performance of the code on the abilities of the compiler
if its so easy to avoid that? As a bonus, the resulting code is
also smaller, contains less debug information, is being compiled
faster.

And then, I still wait to hit a case where the stricter type
checking prevents me from doing something dumb. But maybe it is
just me because I'm lacking the necessary imagination. Can
anyone give me an example where the stricter type checking has
actually helped someone in real-world coding?

Thanks,
Thomas.







More information about the Libstdc++ mailing list