Improved comments in enginecontrol and use of std::size_t for bufferSize accross the codebase

[JoergAtGithub]

This is a spin-off of #13172 (comment) to keep the changes not related to Macros out of that PR.

[Swiftb0y]

two quick notes:

1. I'm fairly certain size_t is the C nomenclature, the proper C++ name/type live in std, so std::size_t.
2. While I prefer to use std::size_t when doing indexing especially in realtime code for compatibility with std containers, it does go against Qt's mantra of using int (at least in their external APIs). Previous experiments have also shown that MSVC is apparently worse at autovectorizing buffer indexes that use size_ts rather than ints, which was the reason to typedef SINT to int rather than size_t.

I'd prefer if you can take care of 1.
2. I just wanted to mention so you're aware even though I don't personally think its a strong argument against size_t.

[daschuer]

mixxx/src/util/types.h

Line 13 in edae0ca

typedef std::ptrdiff_t SINT;

And Qt used int in Qt5 an ssize_t form Qt6
https://doc.qt.io/qt-6/qttypes.html#qsizetype-typedef

We have also a pending discussion to pass all buffers as a std::span, wich includes std::size_t a size.

This however goes against our alternative attempt to pass buffers without the stereo assumption. This issue is also visible in the #13654

So maybe we want an own span type with a frame size?

[Swiftb0y]

couple more comments. LGTM otherwise though

[Swiftb0y]

was this a confused clang-format or where is the bogus indentation from?

[JoergAtGithub]

I think this is not clang-format itself. I've clang-format support enabled in VisualStudio and it formats it like this:

but if I ran pre-commit, it looks like this:

I will not address this in this PR!

[Swiftb0y]

I will not address this in this PR!

Not forcing you to, though I wonder whether it makes sense to just enforce yourself and skip clang-format...

[JoergAtGithub]

This I can do, but not fixing the script

[JoergAtGithub]

Done! CI fails now as expected.

[Swiftb0y]

yeah thats fine for me. Since it only runs on the diff we shouldn't be bothered by it again after the merge, right?

[Swiftb0y]

So maybe we want an own span type with a frame size?

In the long-term, yes. As I pointed out previously std::mdspan would likely be the good solution here, we just need to wait for GCC to implement it (or use Kokkos::mdspan).

[Swiftb0y]

I think transitioning to std::size_t and std::span in the meantime is a good enough solution. In actual audio code, we may want to leverage std::simd anyways (which is currently being proposed for standardization in C++26).

[Swiftb0y]

LGTM otherwise. Thank you.

[Swiftb0y]

Thank you. LGTM.