Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualcr88192

Posted 09 April 2013 - 01:05 PM

"int[] blk=new int[64];" vs "int blk[64];";
"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[64];
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
aggregates errors
 
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...


#1cr88192

Posted 09 April 2013 - 12:54 PM

"int[] blk=new int[64];" vs "int blk[64];";
"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[64];
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
aggregates errors
 
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, ...).

 

despite all this, it actually went pretty well...


PARTNERS