| |
| |
I m following this with a certain awe. Defining a macro has tons of side effects, and defining such simple word as `putchar` in a system header is horrible. Anyway, we can fight macros with macros... .
Not sure it that would compile, or work in this context, but if we define our own macro, we should be able to generate the same code, even if putchar is a macro. I would add `putc` as a method, so even if there is #define putchar(x) putc(x, stdout) somewhere, we would still compile correctly:
#define putchar(x) putc(x, stdout)
class Fl_Terminal { int putc(int c, FILE *); // 2nd arg is ignored #ifdef putchar #define FL_TERMINAL_PUTCHAR putchar int FL_TERMINAL_PUTCHAR(int c); #undef FL_TERMINAL_PUTCHAR #else int putchar(int c); #endif
}
so calling myTerminal->putchar('a'); should do the right thing in either case, and Fl_Terminal::putchar() should exist, even if putchar is a macro.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/86048e6a-4d55-4b11-a9b9-6215ed7117fbn%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |
