Hacker News Reader

Comment by d0m | Hacker News Reader

"(Talking about C++ macro) [...] Well fuck you. If you take it out, I can't #include stdio.h, and I can't implement awesome assert-like macros. End of discussion."

This statement is simply wrong, and saying "End of discussion" is useless, if not plain stupid.

It's like saying: 1+1 = 3, End of discussion.

View on HN

I honestly can't begin to contemplate how you expect stdio.h to work (without writing extra wrappers) if you don't support macros and a preprocessor.

Some of the "functions" in there are macros.

import_c<stdio.h>

You can import C headers without your language being a superset of C.

Yes. Many a time I have wished to import a library's symbols without importing its macros. Or better yet, import its symbols under alternate names. "namespace x = import<y.h>" anyone?

Yes, the biggest problem with #includes is the namespace cross contamination they can cause. I once tracked a build problem down to someone #defining usleep(time) to 'sleep(time/1000)' (or something similar). Problem was, usleep was included later, so the definition of the real usleep got replaced with gibberish that did math inside a function declaration.

I'm really looking forward to maintaining your code.

Interesting idea, but how are you going to support "functions" like getc() that are actually macros?

Most C libraries already implement those as both functions and macros. The macro definition usually shadows the function definition, but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. The macro is just a wrapper for a function anyway in glibc (the internal _IO_getc), so there's no real reason to retain it except for historical reasons. If macros were eliminated in user code, you'd just use the function versions. I think having them as macros at all is an efficiency hack dating back to the days when compilers didn't do function inlining.

> but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function.

Are you sure about this?

Yes (the macro must be define as

     #define getc(stream) ...

of course, but that's the only legal definition anyway).

("Free-standing implementations" like kernels have a lot of freedom to muck with the standard library. But that's not really relevant.)

Ah okay, I understand what you meant now. One thing however - if it is a macro, couldn't it just be:

  #define getc fgetc_or_similar

At least C89/90 only mentions that if it is a macro, it may evaluate arguments more than once (but then it may not, as in the above case).

Yes and no. Yes, that is a valid #define; but the following program must work:

    #include <stdio.h>
    #undef getc
    int main(void) {
        getc(stdin);
        return 0;
    }

so it cannot be implemented as only a macro.

Reply on news.ycombinator.com