On 2016-09-07 09:10:09 -0500, Derek Martin wrote:
> On Wed, Sep 07, 2016 at 01:26:35PM +0200, Vincent Lefevre wrote:
> > > Firstly, I'll note that, given the existing macros don't seem to have
> > > caused anyone any grief, the exact macro syntax is largely an academic
> > > consideration. =8^)
> >
> > Not really. Code gets modified. So, bugs may appear in the future.
> > This happened in MPFR: my new code wasn't working and I was wondering
> > why... until I found that someone who wrote macros forgot parentheses.
>
> Sure, but if it ever happened, the coder would notice that it broke
> when the change was made, and fix it as required.
Not necessarily. And it can take time to find the cause.
> > The example I gave was invalid C code with the above macro, and it
> > becomes valid if do ... while(0) is used. Here's a simple example:
>
> But:
>
> $ cat macro.c
> #include <stdio.h>
>
> #define foo(A) ({ printf("%s\n", (A)); })
This is a GCC extension.
> Like I said, I'm familiar with the do {} while (0) construct, but I
> could swear I ran into an odd case where it caused some sort of
> problem...
That's *very* surprising.
> Then again, I tend to dislike macros in general, and would rather use
> a function, and inline it if possible/sensible. If your program is
> performance-sensitive enough to worry about setting up the function
> call, then you'll probably also want to eliminate the extra branch
> instructions that the do/while construct might (or might not)
> generate, depending on compiler optimizations.
Yes, macros are a bad idea. They can also break type checking.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
