"int blk=new int;" vs "int blk;";
"for(i=0; i<n; i++)ct[b+i]=Foo(cs[b+i]);" vs "while(cs<cse)*ct++=Foo(*cs++);";
"ct[i]=(byte)((((int)cs[i])*xsc+2048)>>12);" vs "*ct++=((*cs++)*xsc+2048)>>12;"
var blk = new int;
var ct = cs.Skip(b).Take(n).Select(Foo);
var ct = cs.Select(v => (byte)((v*xsc + 2048) >> 12));
yes, but these wont necessarily do exactly the same thing.
trivial examples were used to illustrate the sorts of basic differences, but the actual code is often not-so-pretty, and not necessarily things that map well to Select or even "foreach()". (mappings are not usually 1:1, we typically work with pieces of much larger input/output arrays, ...).
IOW: how you might use an array in a video codec or similar is not necessarily the same as how it might often be used in general programming.
easier to read, deferred, wont crash because of array arithmetic.
I don't have to define cse or ct earlier in the code
scalable, I can parallelize easily.
all are 1 line as expected, not crushed together
these are the things I like about programming.
there may be reasons for a person wanting to do things C-style.
nicest is if C-style code works nicely.
well, and also because for some of these sorts of code, there was a lot of copying back and forth between C and C# implementations of the codec, trying to keep them roughly in-sync, so avoiding things that would hinder easily copy/pasting code-fragments was preferable in this case. granted, yes, it probably could have been a little easier if I were using unsafe, but I ended up instead opting with wrapped struct based "box pointers" (in C# it is structs + overloaded operators, in C it was typedefs, ...). (basically: glossing over language differences...).
despite all this, it actually went pretty well...