12 ms·

Ten things I love && hate about C

10 points by benhoyt 19y ago

dzorz 19y ago
> And, closer to something I've needed more than once, how do you give your program an int and string version number with only one thing to modify? This is not very elegant, and you have to split your version number to major and minor part, but it does the job. Oh, yes, minor version must be between 0 and 99 (inclusive). #define VERSION_MAJOR 2 #define VERSION_MINOR 9 #define VERSION_INT (VERSION_MAJOR * 100 + VERSION_MINOR) #define STRINGIFY2(x) #x #define STRINGIFY(x) STRINGIFY2(x) #if VERSION_MINOR<10 #define VERSION_STR STRINGIFY(VERSION_MAJOR) ".0" STRINGIFY(VERSION_MINOR) #else #define VERSION_STR STRINGIFY(VERSION_MAJOR) "." STRINGIFY(VERSION_MINOR) #endif
- dzorz 19y ago
  And if you don't need string constant, but just a string, then you can use the following (I'm not sure about portability though): #include <stdio.h> #define VERSION_INT 3209 #if VERSION_INT < 100 #error VERSION_INT less than 100 #elif VERSION_INT < 1000 #define VERSION_STR (char[]){VERSION_INT/100+'0','.',(VERSION_INT%100)/10+'0',(VERSION_INT%10)+'0',0 #elif VERSION_INT < 10000 #define VERSION_STR (char[]){VERSION_INT/1000+'0',(VERSION_INT%1000)/100+'0','.',(VERSION_INT%100)/1 #endif int main(void) { printf("%d\n", VERSION_INT); printf("%s\n", VERSION_STR); return 0; } Output: 3209 32.09
- benhoyt 19y ago
  Good stuff. It's that second level of indirection that got me (your STRINGIFY2/STRINGIFY combo).
deleted 19y ago
[deleted]
zandorg 19y ago
11.Speed I'm surprised he doesn't mention this. I get magnitudes of speed (10000%) improvement over other languages after porting them to C.
- Zak 19y ago
  That's a bit of a red herring. Everybody "knows" C is fast, but much of the time, it's no more than twice as fast as some higher level languages (Lisp, ML, Haskell, Java). I'm also willing to bet that applications where fast matters so much that half the speed is unacceptable are much less common that applications where small matters so much that twice the size is unacceptable.
- geebee 19y ago
  Check out the link that he is responding to in his essay (why should I ever use C again). There's an entertaining argument about speed in there - (I'm paraphrasing here)... If speed is so important, why aren't you writing assembly? The mostly likely answer is that slower C is better than fast assembly. But then why isn't slower <your fave> better than fast C? The logic isn't 100% airtight - it is possible to argue that benefits of C are sufficient to take the performance hit over assembly, but not so great to take the hit from C to Ruby.
  - dzorz 19y ago
    Because C is (mostly) portable, and assembler is not? Lately it became difficult to match C even using hand written assembly. Intel's C compiler will generate auto-vectorized auto-parallelized code (not as good as carefully written assembly, but much better than assembly a novice would write).
- benhoyt 19y ago
  Main reason I didn't mention that is because speed is rarely the main problem in my field (embedded systems). People have used bytecode interpreted Forths (usually a 10x slowdown) on slow micros and it's often good enough. In fact, a C-to-bytecode compiler might be a good idea for size reasons ... but there probably are some out there already.

10 points by benhoyt 19y ago

dzorz 19y ago

> And, closer to something I've needed more than once, how do you give your program an int and string version number with only one thing to modify? This is not very elegant, and you have to split your version number to major and minor part, but it does the job. Oh, yes, minor version must be between 0 and 99 (inclusive). #define VERSION_MAJOR 2 #define VERSION_MINOR 9 #define VERSION_INT (VERSION_MAJOR * 100 + VERSION_MINOR) #define STRINGIFY2(x) #x #define STRINGIFY(x) STRINGIFY2(x) #if VERSION_MINOR<10 #define VERSION_STR STRINGIFY(VERSION_MAJOR) ".0" STRINGIFY(VERSION_MINOR) #else #define VERSION_STR STRINGIFY(VERSION_MAJOR) "." STRINGIFY(VERSION_MINOR) #endif

dzorz 19y ago
And if you don't need string constant, but just a string, then you can use the following (I'm not sure about portability though): #include <stdio.h> #define VERSION_INT 3209 #if VERSION_INT < 100 #error VERSION_INT less than 100 #elif VERSION_INT < 1000 #define VERSION_STR (char[]){VERSION_INT/100+'0','.',(VERSION_INT%100)/10+'0',(VERSION_INT%10)+'0',0 #elif VERSION_INT < 10000 #define VERSION_STR (char[]){VERSION_INT/1000+'0',(VERSION_INT%1000)/100+'0','.',(VERSION_INT%100)/1 #endif int main(void) { printf("%d\n", VERSION_INT); printf("%s\n", VERSION_STR); return 0; } Output: 3209 32.09
benhoyt 19y ago
Good stuff. It's that second level of indirection that got me (your STRINGIFY2/STRINGIFY combo).

deleted 19y ago

[deleted]

zandorg 19y ago

11.Speed I'm surprised he doesn't mention this. I get magnitudes of speed (10000%) improvement over other languages after porting them to C.

Zak 19y ago
That's a bit of a red herring. Everybody "knows" C is fast, but much of the time, it's no more than twice as fast as some higher level languages (Lisp, ML, Haskell, Java). I'm also willing to bet that applications where fast matters so much that half the speed is unacceptable are much less common that applications where small matters so much that twice the size is unacceptable.
geebee 19y ago
Check out the link that he is responding to in his essay (why should I ever use C again). There's an entertaining argument about speed in there - (I'm paraphrasing here)... If speed is so important, why aren't you writing assembly? The mostly likely answer is that slower C is better than fast assembly. But then why isn't slower <your fave> better than fast C? The logic isn't 100% airtight - it is possible to argue that benefits of C are sufficient to take the performance hit over assembly, but not so great to take the hit from C to Ruby.
- dzorz 19y ago
  Because C is (mostly) portable, and assembler is not? Lately it became difficult to match C even using hand written assembly. Intel's C compiler will generate auto-vectorized auto-parallelized code (not as good as carefully written assembly, but much better than assembly a novice would write).
benhoyt 19y ago
Main reason I didn't mention that is because speed is rarely the main problem in my field (embedded systems). People have used bytecode interpreted Forths (usually a 10x slowdown) on slow micros and it's often good enough. In fact, a C-to-bytecode compiler might be a good idea for size reasons ... but there probably are some out there already.