Tafelmusik

An Illusory Intertwingling of Reason and Response

Tech: Yes, I’m a geek. I admit it. At least I’m not a nerd!

Tafel :: tech

Tuesday, February 06, 2007

Finally, a use for the pre-increment operator!

Okay, so if you hang out for long enough in programming newsgroups and the like, you eventually realize that there are two schools of thought, "both alike in dignity,"1 regarding increment operators: the pre-incrementers and the post-incrementers.

The philosophical and stylistic argument for pre-increment runs something like, "It reads more intuitively to say "increment i", rather than "i increment". The argument for post-increment is generally one of appearance: "i++ looks neater than ++i".

I'm firmly on the i++ side when it doesn't matter. However, there is a valuable semantic difference between the two, which until this moment I never had cause to appreciate: it saved me an extra case in a well-travelled switch. Sold as I have my soul to hand-optimization, that extra case irked me.

I'm using a simple format-string parser, and of course I'm using a while loop to iterate over the format string. (I dislike the fact that for loops can usually be outperformed by a more efficient while.) To save one conditional per iteration, I cast it in do . . . while form. However, the loop was conditional on *fmt++, which is of course the value of the current character, which is then incremented. The loop will break at the \0 at the end of the format string.

More precisely, it will break after processing the \0 through the state machine within the loop. When I noticed these nils getting through, and tracked them down, I was so used to post-incrementing that my first reaction was to put a case '\0': break; line in the switch of the state machine.

The value returned by post-increment is the original value: increment takes place after reading the value of the variable. Pre-increment increments the variable and returns the new value.

So, now, with a slightly less-elegant while(*++fmt) (which really looks like it shouldn't work!), it hums along nicely. And since the format function is called every time a data record is recovered, the time savings over thousands of entries should be noticeable if not substantial, even given the fact that format strings will generally be under a dozen characters.

Oh, what's it for? Unsatisfied with Analog (or any other log analysis program I've yet tried -- though I'm going to give Sawmill a spin, if only for the sake of the great beta-testing program they have), I'm writing my own log analyzer. Perl can bite me: I'll practically extract all the reports I want in a compiled language!


1.

Two households, both alike in dignity,
In fair Verona, where we lay our scene,
From ancient grudge break to new mutiny,
Where civil blood makes civil hands unclean.
From forth the fatal loins of these two foes
A pair of star-cross'd lovers take their life;
Whose misadventured piteous overthrows
Do with their death bury their parents' strife.
The fearful passage of their death-mark'd love,
And the continuance of their parents' rage,
Which, but their children's end, nought could remove,
Is now the two hours' traffic of our stage;
The which if you with patient ears attend,
What here shall miss, our toil shall strive to mend.

from Romeo and Juliet, Prologue, by William Shakespeare

Technorati