An easy one:
Code:int a[] = {11,12,13,14,15}; int* ap = a - 1;
An easy one:
Code:int a[] = {11,12,13,14,15}; int* ap = a - 1;
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
And yet that's correct
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Are you absolutely sure? The standard is far more precise about what operations are allowed on pointers and when than what any implementation actually enforces.
Hmm, according to the C faq link it's not correct.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I meant Dave was correct on how he interpreted the code. It's a way to implement a unit-based array.
EDIT: I was actually unware at the fact that despite there existing no dereferencing it could still produce undefined behavior. But Dave hit it on the nail at the code usage.
Last edited by Mario F.; 11-11-2006 at 01:01 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
But is there actually systems that behaves differenty than expected, trying to "wrap around" for example?Originally Posted by Mario F.
> But is there actually systems that behaves differenty than expected, trying to "wrap around" for example?
Some people don't like to admit they were wrong, apparently.
While the link provided by Dave explains why it is undefined behavior, the following link from the Numerical Recipes book website shows an extract of the new Numerical Recipes for C++ book. Take a look at page 10. It's worth your time... although probably make you mad.
http://www.numerical-recipes.com/cpppages/chap1sel.pdf
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
For fun:Code:void foo(unsigned int value) { unsigned int bit; for ( bit = /* msb */(~0U >> 1) + 1; bit > 0; bit >>= 1 ) { putchar("01"[!!(value & bit)]); } putchar('\n'); }
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Ain't that just a base 2 itoa, printing directly?
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Mario F: I think you missunderstod me, I was just being curious.
Last edited by TriKri; 11-11-2006 at 06:33 PM.
Oh. I have. Sorry. I read that as a rethorical question.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Yeah. I was kind of shooting for something along the line of, "the !!(value & bit) results in a one or a zero if the selected bit is set in value or not, so you can safely index into the string literal", or something.Code:putchar("01"[!!(value & bit)]);
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
what if you'd do (value & bit) != 0 ? isnt that either 0 or 1 ?
But!! isn't!! double!! exclaimation!! so!! leet!! ??!!
Code:#include <stdio.h> void J(char*a){int f,i=0,c='1';for(;a[i]!='0';++i)if(i==81){ puts(a);return;}for(;c<='9';++c){for(f=0;f<9;++f)if(a[i-i%27+i%9 /3*3+f/3*9+f%3]==c||a[i%9+f*9]==c||a[i-i%9+f]==c)goto e;a[i]=c;J(a);a[i] ='0';e:;}}int main(int c,char**v){int t=0;if(c>1){for(;v[1][ t];++t);if(t==81){J(v[1]);return 0;}}puts("sudoku [0-9]{81}");return 1;}
Ah! Not the leet thing again!
