On Mar 1, 2015, at 22:49 , Patrick J. Collins <[email protected]> wrote: > > Would you argue that I should in fact be using C arrays since they are > light-weight, fast, etc... ?
For my money, the problem with the code you showed is that, at its heart, it is a concise mathematical calculation, but you’d never know it because it's buried in a lot of verbiage. In pure C, it’d be a couple of lines of code that exhibited the calculation very clearly. In the old days, therefore, C would have been much clearer. However, modern Obj-C can get very close if you use subscript and boxing operators (‘[…]’ and ‘@(…)’). Even so, C probably still has an advantage in clarity, especially if you can avoid the extra step of converting a buffer into a collection. The other factor in favor of C-ish-ness is that it’s more usual to do audio that way, for reasons of efficiency, even if performance is not important to you in this particular case. Audio coding experts who read your code may prefer to read C than Obj-C. OTOH, the extra verbiage would be justified if your manipulation included things that tend to be error-prone or inscrutable in C, such as re-arranging and re-sizing buffer arrays. Lastly, I may not not be reading your code carefully enough, but it seems that you don’t even need to create your ‘window’ buffer, since the new sample buffer elements can be computed directly, element by element. That doesn’t change your question, though it does mean that your example doesn’t really illustrate the problem.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
