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