[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: "Fixed" post-increment operators on iterators
From:       Esben Mose Hansen <kde () mosehansen ! dk>
Date:       2004-10-31 12:27:48
Message-ID: 200410311327.48413.kde () mosehansen ! dk
[Download RAW message or body]

On Sunday 31 October, 2004 12:59, Frederik Schmid wrote:

> > QStringList::ConstIterator itEnd = matches.end();
> > for(QStringList::ConstIterator it = matches.begin(); it != itEnd; ++it)
> >      _keyList->insertItem(*it);
[...]
> The compiler will (almost certainly) move loop-conditions out ouf the
> loop, so no need to add extra lines in this case.

I have always wondered about that. Unless the container is const, how can the 
compiler know that mycontainer->end() always returns the same value?

Also, why is it we don't use STL? The above could be written as (untested)

std::foreach(matches.begin(), 
           matches.end(), 
           std::bind1st(std::mem_fun(&KeyList::iterator), _keyList));

Or, if QT properly supports the STL (or KDE writes the supporting functors):

std::copy(matches.begin(), matches.end(), std::back_inserter(*_keyList));

Those algorithm avoids all these subtle pitsfalls, and the code is (IMHO) much 
clearer.

Just me 0.02€

-- 
regards, Esben
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]