Update audio code to use size_t more correctly,

Update audio code to use size_t more correctly,
webrtc/modules/audio_coding/main/ portion.

This is a piece of https://codereview.webrtc.org/1230503003 , split out to a
separate change to make reviewing easier.

BUG=chromium:81439
TEST=none

[Peter Kasting, 2015-07-10 00:14:55]

pkasting@chromium.org changed reviewers:
+ kwiberg@webrtc.org

[kwiberg-webrtc, 2015-07-12 17:39:26]

lgtm

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (left):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:94: int i = n
- 1;
Hmm. This code already jumps through all the hoops needed for an unsigned loop
variable, even though it's signed. Curious...

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:95: for
(size_t n = frame.samples_per_channel_; n > 0; --n) {
Maybe n != 0 now that it can't be negative.

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/test/PCMFile.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/test/PCMFile.cc:154: for (k = 0; k <
audio_frame.samples_per_channel_; k++) {
Merge lines 153 and 154 while you're at it?

[Peter Kasting, 2015-07-13 02:46:27]

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (left):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:94: int i = n
- 1;
On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> Hmm. This code already jumps through all the hoops needed for an unsigned loop
variable, even though it's signed. Curious...

That's probably a sign that I updated the code to jump through those hoops as a
precursor change, to minimize the deltas in this later enormous patch.

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:95: for
(size_t n = frame.samples_per_channel_; n > 0; --n) {
On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> Maybe n != 0 now that it can't be negative.

Is one preferred over the other for some reason?  It seems like both should be
optimized the same way, but "> 0" is more restrictive from a reader's
perspective, which I think is a good thing, since it means you don't have to
mentally think, "oh, size_t is unsigned, so this can't be negative, so it really
means > 0".

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/test/PCMFile.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/test/PCMFile.cc:154: for (k = 0; k <
audio_frame.samples_per_channel_; k++) {
On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> Merge lines 153 and 154 while you're at it?

I'm willing to add that to the misc. cleanup changeset if you want, but I'm
intentionally avoiding doing even a single "incidental cleanup" change in a CL
that touches some 450 files.

[Peter Kasting, 2015-07-13 22:24:23]

On 2015/07/13 at 02:46:27, Peter Kasting wrote:
>
https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
> webrtc/modules/audio_coding/main/test/PCMFile.cc:154: for (k = 0; k <
audio_frame.samples_per_channel_; k++) {
> On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> > Merge lines 153 and 154 while you're at it?
> 
> I'm willing to add that to the misc. cleanup changeset if you want, but I'm
intentionally avoiding doing even a single "incidental cleanup" change in a CL
that touches some 450 files.

FYI, I added this to the "misc. cleanup" changeset.

[kwiberg-webrtc, 2015-07-15 01:05:01]

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:95: for
(size_t n = frame.samples_per_channel_; n > 0; --n) {
On 2015/07/13 02:46:26, Peter Kasting wrote:
> On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> > Maybe n != 0 now that it can't be negative.
> 
> Is one preferred over the other for some reason?  It seems like both should be
> optimized the same way, but "> 0" is more restrictive from a reader's
> perspective, which I think is a good thing, since it means you don't have to
> mentally think, "oh, size_t is unsigned, so this can't be negative, so it
really
> means > 0".

The compiler is surely smart enough to realize that they're the same operation
for unsigned numbers. My opinion is that != 0 is more readable for unsigned
numbers, since that's what the operation actually is; when you wrote > 0, I had
to double check that n was actually unsigned, since that operation would (in my
head) have made more sense for a signed number.

It seems our intuitions about what's most natural here differ. But the
difference isn't large, and the compiler can't possibly care, so choose based on
whether getting the last word or sucking up to reviewers is more important to
you. :-)

[Peter Kasting, 2015-07-15 06:30:09]

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:95: for
(size_t n = frame.samples_per_channel_; n > 0; --n) {
On 2015/07/15 at 01:05:00, kwiberg-webrtc wrote:
> On 2015/07/13 02:46:26, Peter Kasting wrote:
> > On 2015/07/12 at 17:39:26, kwiberg-webrtc wrote:
> > > Maybe n != 0 now that it can't be negative.
> > 
> > Is one preferred over the other for some reason?  It seems like both should
be
> > optimized the same way, but "> 0" is more restrictive from a reader's
> > perspective, which I think is a good thing, since it means you don't have to
> > mentally think, "oh, size_t is unsigned, so this can't be negative, so it
really
> > means > 0".
> 
> The compiler is surely smart enough to realize that they're the same operation
for unsigned numbers. My opinion is that != 0 is more readable for unsigned
numbers, since that's what the operation actually is; when you wrote > 0, I had
to double check that n was actually unsigned, since that operation would (in my
head) have made more sense for a signed number.
> 
> It seems our intuitions about what's most natural here differ. But the
difference isn't large, and the compiler can't possibly care, so choose based on
whether getting the last word or sucking up to reviewers is more important to
you. :-)

When I'm working with webrtc code (where I'm basically an interloper) and trying
to earn reviewer approval for montrous patchsets that change hundreds of files,
I'll choose sucking up to reviewers :)

[Peter Kasting, 2015-07-17 00:12:08]

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
File webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc (right):

https://codereview.webrtc.org/1225133003/diff/1/webrtc/modules/audio_coding/m...
webrtc/modules/audio_coding/main/acm2/audio_coding_module_impl.cc:95: for
(size_t n = frame.samples_per_channel_; n > 0; --n) {
On 2015/07/15 at 06:30:09, Peter Kasting wrote:
> On 2015/07/15 at 01:05:00, kwiberg-webrtc wrote:
> > It seems our intuitions about what's most natural here differ. But the
difference isn't large, and the compiler can't possibly care, so choose based on
whether getting the last word or sucking up to reviewers is more important to
you. :-)
> 
> When I'm working with webrtc code (where I'm basically an interloper) and
trying to earn reviewer approval for montrous patchsets that change hundreds of
files, I'll choose sucking up to reviewers :)

Done.