Ten things I love && hate about C | Hacker News Reader

Ten things I love && hate about C

blog.micropledge.com

10 pointsbenhoyt8 comments

> 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

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

Good stuff. It's that second level of indirection that got me (your STRINGIFY2/STRINGIFY combo).

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.

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.

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.

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).

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.

Reply on news.ycombinator.com