| |
| |
On 3/27/24 17:27 'melcher....@googlemail.com' via fltk.coredev
wrote:
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.
I agree with this statement. 100%.
Anyway,
we can fight macros with macros... .
I don't think this would work, even if we wanted, see below.
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.
Fortunately [1] this doesn't work for several reasons:
1. The method in Fl_Terminal is putchar(...) with either three or
four parameters whereas the well-known putchar(c) macro has only one
parameter. In a quick test I believe that I saw that
the preprocessor chokes already (wrong number of arguments).
2. Lines with macros are interpreted iteratively until no macro
expansion takes place anymore. Thus, even if we defined "FL_TERMINAL_PUTCHAR" as "putchar", then putchar would be replaced
with "putc()" again. And, again, the
number of parameters doesn't match.
3. I don't think (i.e. I'm not sure) that this construct
would be immune against defining 'putchar' either before or after
the inclusion of Fl_Terminal.H if it would make it through the
preprocessor at all. Maybe it works, maybe not, I'm not willing to
"test" this though.
That said, I'm glad that this doesn't work (AFAICT). It would only
add more to the confusion. Trying to make this work would IMHO be a
waste of time, particularly because there's a very simple
solution: rename the offending Fl_Terminal::putchar(...)
method.
Footnote:
[1] Yes, I mean "fortunately". This idea would IMHO make the
code less transparent, much harder to maintain ("why does this weird
construct of macros exist in the first place), and supposedly more
fragile. What would happen if putchar is defined as a macro with an
entirely different meaning or set of parameters?
--
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/8b1dc06e-3aba-4006-a241-edc1443f213e%40aljus.de.
[ Direct Link to Message ] | |
|
| |
