audiomixerboard size_t clean-up

[pljones]

Short description of changes

Small patch to audiomixerboard.cpp to clean up warnings in Qt Creator. Changes int to size_t where appropriate and handles any casts required.

CHANGELOG: Refactor: use size_t for vector and array indexes that must not be negative

Context: Fixes an issue?

Fixes warnings in Qt Creator in one file. Warnings of a similar nature are also available.

Does this change need documentation? What needs to be documented and how?

No.

Status of this Pull Request

I use it in the client I run when jamming and it seems okay.

What is missing until this pull request can be merged?

Needs a review.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

AUTOBUILD: Please build all targets

[ann0see]

Is there any valid reason why size_t is prefered by Qt? I doubt we get over the positive integer range anywhere.

[ann0see]

Approving based on reading.

[hoffie]

I don't see anything wrong here, but I can't say that I'm able to assess that everything is right... ;)

Fixes warnings in Qt Creator in one file. Warnings of a similar nature are also available.

What are those warnings?

[pljones]

What are those warnings?

I wish cut-n-paste from the warnings was simple. They seemed to be Qt IDE rather than Compiler warnings (so the compile output didn't show them). Whilst correct (i.e. size_t can hold a larger number than int as it's unsigned), the int usage is also correct in places (we use -1 as an invalid index into an array or list, which has an index type of size_t, so doing something like

void methodName(SomeArrayType someArray) {
  int i = sizeof(someArray) - 1;
  if (i == INVALID_INDEX) {
    return;
  }
  ...
}

will get a warning, as someArray could be so big that even taking one off the size is still too large a positive number for the int to hold. In practice, we generally use no extent over about 256 (sound card buffer size is probably the worst - maybe 4K? - still well under the number an int can hold).