If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This behavior is the reason why prefix increment, ++s, should be preferred unless you have a specific need for the postfix version. It's not only less confusing, it can in some cases be more efficient.

This behavior is the reason why prefix increment, ++s, should be preferred unless you have a specific need for the postfix version. It's not only less confusing, it can in some cases be more efficient.

Re: A question regarding *s++

Originally Posted by Lindley

This behavior is the reason why prefix increment, ++s, should be preferred unless you have a specific need for the postfix version. It's not only less confusing, it can in some cases be more efficient.

Ok, now that we have a thread about that specific topic, I can ask this...

From plain old C I'm used to prefer the post-increment version unless it is specifically required otherwise, simply because it looks more familiar to me.

Am I right to assume that it wouldn't make a difference in terms of efficiency in C++ as long as it's about POD types?

It looks reasonable to me that I get a performance penalty if I use post-increment on non-POD types and I somehow process the result of that operation, because it is likely to require creation of a temporary object. But does it really make any difference if I don't use the result of the increment operation in further processing?

Re: A question regarding *s++

Ok, now that we have a thread about that specific topic, I can ask this...

From plain old C I'm used to prefer the post-increment version unless it is specifically required otherwise, simply because it looks more familiar to me.

Am I right to assume that it wouldn't make a difference in terms of efficiency in C++ as long as it's about POD types?

It looks reasonable to me that I get a performance penalty if I use post-increment on non-POD types and I somehow process the result of that operation, because it is likely to require creation of a temporary object. But does it really make any difference if I don't use the result of the increment operation in further processing?

In a single sentence, "postfix is never faster, and sometimes slower".

Under these conditions, there really is no reason to use postfix unless you need to.

As for your question of taste ("prefering postfix over prefix"), if you start getting experience in C++, or work with people who have a C++ back ground, you will notice that prefix is the preferred way, and postfix will start looking weird.

PS: The compiler may or may not optimize away and performance penalty, but why take the chance?

Is your question related to IO?
Read this C++ FAQ LITE article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.

Re: A question regarding *s++

Ok, now that we have a thread about that specific topic, I can ask this...

From plain old C I'm used to prefer the post-increment version unless it is specifically required otherwise, simply because it looks more familiar to me.

Am I right to assume that it wouldn't make a difference in terms of efficiency in C++ as long as it's about POD types?

It looks reasonable to me that I get a performance penalty if I use post-increment on non-POD types and I somehow process the result of that operation, because it is likely to require creation of a temporary object. But does it really make any difference if I don't use the result of the increment operation in further processing?

The main argument for me to not using post-increment on class types isn't the possible lack of efficiency but that the behavior is different to that on POD types. Look at the following code (which was a C sample code in Stroustrup's Annotated C++ Reference)

Code:

while (*p++ = *q++);

When p and q are char arrays the above is a perfect strcpy. When p and q are class types there is no way to let the post-increment on the right-hand happen after the assignment.

If you then see that increment operation on class types mainly is done for containers and their iterators you probably will decide for prefix increment same as me and I promise that it will look 'more familiar' to you within a very short period ;-)

Re: A question regarding *s++

Originally Posted by itsmeandnobodyelse

When p and q are class types there is no way to let the post-increment on the right-hand happen after the assignment.

Sorry, but I do not quite understand the problem that you are presenting. Now, order of evaluation is implementation defined, but here it seems quite clear that the dereference of q must happen before its post-increment. Therefore, how does it matter if the assignment happens before or after the post-increment? With the normally expected semantics, the net effect should be the same, i.e., similiar to "a perfect strcpy".

Re: A question regarding *s++

Originally Posted by laserlight

Sorry, but I do not quite understand the problem that you are presenting. Now, order of evaluation is implementation defined, but here it seems quite clear that the dereference of q must happen before its post-increment. Therefore, how does it matter if the assignment happens before or after the post-increment? With the normally expected semantics, the net effect should be the same, i.e., similiar to "a perfect strcpy".

Re: A question regarding *s++

Originally Posted by laserlight

Sorry, but I do not quite understand the problem that you are presenting. Now, order of evaluation is implementation defined, but here it seems quite clear that the dereference of q must happen before its post-increment. Therefore, how does it matter if the assignment happens before or after the post-increment? With the normally expected semantics, the net effect should be the same, i.e., similiar to "a perfect strcpy".

I'm being pedantic, but since you rarely make a mistake, I thought I'd chip in here... the part in bold is not correct. The precedence of the post increment and post decrement operators is higher than the precedence of the dereference operator. Therefore for an ISO Standard compliant compiler the post increment must happen before the dereference.

Re: A question regarding *s++

Originally Posted by PredicateNormative

I'm being pedantic, but since you rarely make a mistake, I thought I'd chip in here... the part in bold is not correct. The precedence of the post increment and post decrement operators is higher than the precedence of the dereference operator. Therefore for an ISO Standard compliant compiler the post increment must happen before the dereference.

No worries, we need to be pedantic here. Yes, your observation is correct. Consequently, itsmeandnobodyelse's same assertion is correct. However, itsmeandnobodyelse's assertion about there being a problem is wrong, assuming that the implementation follows normal semantics. The reason for my mistake is that I am thinking of the result of p++ being the original p. Therefore, *p will still dereference the value of the original p, unless for some reason postfix operator++ is implemented to return the modified p, which goes against normal semantics.

Is your question related to IO?
Read this C++ FAQ LITE article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.

Re: A question regarding *s++

Originally Posted by laserlight

No worries, we need to be pedantic here. Yes, your observation is correct. Consequently, itsmeandnobodyelse's same assertion is correct. However, itsmeandnobodyelse's assertion about there being a problem is wrong, assuming that the implementation follows normal semantics. The reason for my mistake is that I am thinking of the result of p++ being the original p. Therefore, *p will still dereference the value of the original p, unless for some reason postfix operator++ is implemented to return the modified p, which goes against normal semantics.

It was only that little bit about precedence I highlighted in bold that I disagreed with, I most certainly agree with everything else that you are saying about itsmeandnobodyelse assertion.

It would seem to me there is something wrong with the post-increment operator implementation in itsmeandnobodyelse's MyString class.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.