Replacing post-increment with pre-increment for consistency

Replacing post-increment with pre-increment for
consistency

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=242123

[commit-bot: I haz the power, 2013-12-19 08:57:58]

No comments yet.

[amogh.bihani, 2013-12-19 08:58:53]

On 2013/12/19 08:57:58, I haz the power (commit-bot) wrote:
> No comments yet.

Please review. Thank you

[Ami GONE FROM CHROMIUM, 2013-12-19 21:21:01]

+acolwell to CC as FYI since he wrote the code originally (before it moved
around a few times)

https://codereview.chromium.org/119043002/diff/1/content/renderer/media/webme...
File content/renderer/media/webmediaplayer_util.cc (right):

https://codereview.chromium.org/119043002/diff/1/content/renderer/media/webme...
content/renderer/media/webmediaplayer_util.cc:34: for (size_t i = 0; i <
ranges.size(); ++i) {
CL description says "to improve efficiency" but AFAICT Release builds of this
file before and after this change generate bit-exact results, because clang is
smart enough to make this change itself.  Do you have a toolchain where this is
not the case?

Using pre-increment instead of post-increment for PODs is rarely/never a
performance win, but it can be a readability win due to consistency with non-POD
pre-increment (where efficiency _can_ be an issue).

So, this change LGTM as long as you update the summary & description to
something more apt, like: "Replace post-increment with pre-increment for
consistency".

[amogh.bihani, 2013-12-20 12:05:07]

On 2013/12/19 21:21:01, Ami Fischman (OOO Dec23-Jan5) wrote:
> +acolwell to CC as FYI since he wrote the code originally (before it moved
> around a few times)
> 
>
https://codereview.chromium.org/119043002/diff/1/content/renderer/media/webme...
> File content/renderer/media/webmediaplayer_util.cc (right):
> 
>
https://codereview.chromium.org/119043002/diff/1/content/renderer/media/webme...
> content/renderer/media/webmediaplayer_util.cc:34: for (size_t i = 0; i <
> ranges.size(); ++i) {
> CL description says "to improve efficiency" but AFAICT Release builds of this
> file before and after this change generate bit-exact results, because clang is
> smart enough to make this change itself.  Do you have a toolchain where this
is
> not the case?
> 
> Using pre-increment instead of post-increment for PODs is rarely/never a
> performance win, but it can be a readability win due to consistency with
non-POD
> pre-increment (where efficiency _can_ be an issue).
> 
> So, this change LGTM as long as you update the summary & description to
> something more apt, like: "Replace post-increment with pre-increment for
> consistency".

ok, noted. thank you for the review.

[commit-bot: I haz the power, 2013-12-20 12:08:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/amogh.bihani@samsung.com/119043002/1

[commit-bot: I haz the power, 2013-12-20 17:48:06]

Change committed as 242123