This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Scribit caj@cs.york.ac.uk dies 30/11/2005 hora 16:53:
> > The thing is, in CS courses on compilation, one can learn that it is
> > nowadays a so classic optimization that one can safely expect it
> > from any decent compiler.
> Really? It is trivial in the case of a pointer, or say a
> vector::iterator, which is just a thin wrapper over a pointer. I
> expect it gets much harder for types with more complex iterators.
I don't see the point. I repeat: i would not have even proposed the
modification if I wasn't expecting any decent compiler to do the
following optimization:
void foo(Iterator first, Iterator last)
{
Iterator current = first;
for ( ; current != last; ++current)
do_something(current);
}
}
becomes:
void foo(Iterator first, Iterator last)
{
for ( ; first != last; ++first)
do_something(first);
}
}
So there won't be any one side-effect more than with the current
implementation. FWIW, in the STL I can see (shipped with GCC 4.0.3), the
iterators are already passed by value, so if copying them will trigger
side-effects, it already does...
I don't use them often (never used them, indeed...), but I suspect a
reference could used also:
Iterator & current = first;
Carefully,
Nowhere man
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
Attachment:
signature.asc
Description: Digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |