Re: vector<T>::iterator

["Bo Persson" <bop2 at telia dot com>]

----- Original Message ----- 
From: "Thomas Kunert" <kunert@physik.tu-dresden.de>
To: "Phil Edwards" <phil@jaj.com>
Cc: "Matt Austern" <austern@apple.com>; <libstdc++@gcc.gnu.org>
Sent: Thursday, July 31, 2003 10:17 AM
Subject: Re: vector<T>::iterator


> Phil Edwards wrote:
> > 
> > Somewhere between slim and none, yes.
> > 
> 
> I take this as different from zero.

Just slightly, I guess.

> 
> 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() );

You should try this with the debug version of STLport, where operator*() asserts for v.end() ...


Possibly you could try out

sort(&v[0], &v[0] + v.size());

i you know for certain that v[0] is present. The "easiest code" version above works always.

> 
> because this is almost as simple and possibly much faster. And,
> most importantly, there is _NO LOSS OF TYPE SAFETY_ here. 

There is a potential loss of safety here, by dereferencing a past-the-end iterator.

> 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? 

Why wouldn't one require the compiler to support common idioms?

> As a bonus, the resulting code is
> also smaller, contains less debug information, is being compiled
> faster.

With a better compiler, the code size is the same. I have one of those.

> 
> And then, I still wait to hit a case where the stricter type
> checking prevents me from doing something dumb. 

Maybe it just did!



Bo Persson
bop2@telia.com