need help with std::list of std::string

Started by
15 comments, last by alnite 21 years ago
quote:Original post by alnite
In my case, where the iterator is a class, do you think there's a difference between preincrement and postincrement operators? The operators are overloaded, so the speed depends on how the class overload these operators.


As I said: "A simple rule of thumb is to always use preincrement whenever possible, and only use postincrement if you really need it."

The preincrement operator will return a reference to the iterator after the increment.
The postincrement operator will return a copy of the iterator before the increment.

As copying an iterator could be an expensive operation, you should stick to the preincrement operator.


Update GameDev.net system time campaign - success at last

[edited by - dalleboy on April 2, 2003 4:24:39 AM]
Arguing on the internet is like running in the Special Olympics: Even if you win, you're still retarded.[How To Ask Questions|STL Programmer's Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
Advertisement
quote:Original post by civguy
Argh petewood! You should know by now that there''s no need to "optimize" integer post-increment in any way. It''s as fast as pre-increment by definition.

er... I didn''t say that it wasn''t. ChaosEngine said the compiler could opti mise away post increment and I said, in effect, that it could only do it for integers (which means you don''t need to do it yourself... but you can and might as well if that''s what you intend).

The compiler will be able to see that the integer value isn''t used and will perform pre-increment (as in the case of the loop variable).

If the value is used (eg assigned to another variable) it will do post increment ie create a temporary variable, which can''t be as fast, can it?
quote:pete:
If the value is used (eg assigned to another variable) it will do post increment ie create a temporary variable, which can''t be as fast, can it?

It can and it is. Post-increment simply does the incrementing later than pre-increment. I.e. after the expression, not before it. This assumption of using temporaries comes only from C++ classes'' lousy attempt to mimic this.

a=++x;

inc x, 1
set a, x

a=x++;

set a, x
inc x, 1

I see no temporaries. In latter case the incrementation is just happening after the expression.

Oh, and I didn''t put the optimize in quotes due to your minor typo. I put it because it really isn''t optimizing, but working according to the post-increment''s real definition: increment after expression. It''s not ''do a useless temporary to waste resources just for the heck of it''.
As someone else stated: always use pre-increment as a habit unless you need post-increment.

For primitive data types, there is no gain but for any objects, you will avoid a useless copy.

Just get into the habit...

Regards,
Jeff
Ndatenda civguy
quote:This assumption of using temporaries comes only from C++ classes'' lousy attempt to mimic this .... but working according to the post-increment''s real definition: increment after expression

Your selective use of the word "lousy" is interesting. How is the compiler supposed to handle post-increment of non-POD types if the operator itself needs to be defined by the programmer? In order to adhere to the "real definition" it would almost have to be hardcoded into the compiler how to handle post-increments.
quote:Original post by alnite
In my case, where the iterator is a class, do you think there''s a difference between preincrement and postincrement operators? The operators are overloaded, so the speed depends on how the class overload these operators.

Current project: 2D in Direct3D engine.
% completed: ~35%
Status: Active.


Technically it all depends on what is done inside the pre and post increment operator overload functions. The reason that this does make a difference in this case is because there is a difference in the semantics of pre and post increment:

Pre-increment means: increment this thing and then return the value of this thing after incrementing

Post-increment means: increment this thing and then return the value that it had before incrementing

The reason this makes a difference with your iterator objects is that the STL designers followed the correct semantics I mention above. The only way to return the previous value of the iterator is to make a copy prior to moving to the next element in the container.

This topic is closed to new replies.

Advertisement