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.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
