# optimizing my code (memory usage, postfix and prefix notation, "continue")

This topic is 2023 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello all

I don't usually write posts here, as I can find most information in the books I have, but I really have an interesting question here.

I have the following code (tiny part of a bigger function ofcourse).

line is a string, ll is an int, j is an int and splitchar is a char
The object of this piece of code is to increase j by 1, as long as the characer of line with index j, equals splitchar.
The character of line with index j, before execution of the inner while loop code, always equals splitchar, quaranteed. So j will be increased by at least one.

//some code
int ll = line.length();
int  j(0);
while(j < ll)
{
//some code that uses and changes j, but nothing very important. It doesn't influence the following code or the subject of this topic.
while (j < ll - 1 && line[j] == splitchar)
++j;
//some code
}


I changed the inner while loop to

while (j++ < ll - 1 && line[j] == splitchar)
continue;


or

while (j < ll - 1 && line[++j] == splitchar)
continue; 

which are pretty much the same. Trust me, I've tested everything in detail ;)
Note: postfix or prefix notation is very important here!

Now, my questions are;

1. Does it matter if I write "continue", or empty braces ("{}") in the last two examples, and how does this affect the performance?
2. Which one of these three would have the best performance?

3. Is there an even better possibility?

Performance is not very important in this program, but I really want to know the little details, because it WILL matter in future projects.

Nick

Edited by Nick C.

##### Share on other sites
Edit: Ignore this post, I didn't think it through properly and SiScrane already corrected me.


while (j++ < ll - 1 && line[j] == splitchar)
continue;

or


while (j < ll - 1 && line[++j] == splitchar)
continue;


Both versions are not well-defined C++. The value of j is undefined (see this Wikipedia page). A colleague of mine recently ran into problems because they were working on code that relied on that but then had to change compiler version. Edited by BitMaster

##### Share on other sites
Really? Well, you keep learning. Still, I would agree with SiCrane and avoid the loops even if they are well defined.

##### Share on other sites

Oh those quirky optimization attempts could well go wrong cause it can be undefined behavior when the increment of a variable thats used twice inside a statement happens. The last is always different from the original as j would be increased before accessing the array, which it was not in the original.

Also abusing the continue statement in this way when there is no jump needed looks ugly and a few years ago some compilers without good optimization could even have added a useless jump instruction.

Edit: slight clarification for language lawyers

Edited by wintertime

##### Share on other sites

Nick C., on 27 Mar 2013 - 07:54, said:

Performance is not very important in this program, but I really want to know the little details, because it WILL matter in future projects.

It really won't.

QFE. It won't.

It'd be better

to use the std:string member function find_first_of like so:

[source='cpp']size_t pos = line.find_first_of(splitchar);

if(pos != string::npos)
{
}[/source]

Err. Sorry, reading comprehension fail. Nonetheless the above is good advice for finding the first occurence of splitchar that I'll build on in a bit, so I'll leave it be.

It'd be better[really, this time] to use the std:string member function find_first_not_of like so (if you know that line begins with splitchar):

[source='cpp']size_t pos = line.find_first_not_of(splitchar);

if(pos != string::npos)
{
}[/source]

If you don't know that line begins with splitchar, then you can combine these two member functions like so:

[source='cpp']size_t pos = line.find_first_not_of(splitchar, line.find_first_of(splitchar));

if(pos != string::npos)
{
}[/source]

Edited by Ravyne

##### Share on other sites

while (j < ll - 1 && line[j] == splitchar)
++j;



while (j < ll - 1 && line[++j] == splitchar)
continue; 

Even though I got -2 for pointing out how this is a failed optimization attempt, that code is not equivalent and you should stop trying to microoptimize such irrelevant things when you are likely to introduce bugs.

Edited by wintertime

##### Share on other sites

Even though I got -2 for pointing out how this is a failed optimization attempt, that code is not equivalent and you should stop trying to microoptimize such irrelevant things when you are likely to introduce bugs.

I don't think you were downvoted for suggesting the optimization was useless and an irrelevant micro optimization. You were downvoted because you said it's invoking undefined behavior. It is well defined. I made the same mistake because I didn't think it through properly more than four hours before you though and I was already corrected.

##### Share on other sites

Also abusing the continue statement in this way when there is no jump needed looks ugly and a few years ago some compilers without good optimization could even have added a useless jump instruction.

Its hardly abusing continue. The fact that a compiler might have mishandled it in the past is not an indication of some terrible practice going on. It's probably good to avoid using looping structures solely for side-effects, as someone else pointed out, and there are better tools as I pointed out myself, but if you did it anyways, using continue is probably a better option than empty braces or a semicolon. At least it stands out and says precisely what the intent was. Empty braces might invite the thought that the programmer forgot to fill in the loop body, and an empty statement (a single semicolon) is first of all very easy to miss, and causes really strange errors if you should ever forget or mistakenly delete it.

1. 1
2. 2
3. 3
4. 4
Rutin
19
5. 5

• 14
• 14
• 9
• 9
• 9
• ### Forum Statistics

• Total Topics
632926
• Total Posts
3009252
• ### Who's Online (See full list)

There are no registered users currently online

×