From: Muli Ben-Yehuda <muli@il.ibm.com>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
trivial@kernel.org
Subject: Re: [PATCH] Documentation: Explain a second alternative for multi-line macros.
Date: Sun, 31 Dec 2006 21:45:01 +0200 [thread overview]
Message-ID: <20061231194501.GE3730@rhun.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0612311430370.18269@localhost.localdomain>
On Sun, Dec 31, 2006 at 02:32:25PM -0500, Robert P. J. Day wrote:
> Generally, inline functions are preferable to macros resembling
> functions.
This should be stressed, IMHO. We have too many macros which have no
reason to live.
> -Macros with multiple statements should be enclosed in a do - while block:
> +There are two techniques for defining macros that contain multiple
> +statements.
>
> -#define macrofun(a, b, c) \
> - do { \
> + (a) Enclose those statements in a do - while block:
> +
> + #define macrofun(a, b, c) \
> + do { \
> + if (a == 5) \
> + do_this(b, c); \
> + } while (0)
> +
> + (b) Use the gcc extension that a compound statement enclosed in
> + parentheses represents an expression:
> +
> + #define macrofun(a, b, c) ({ \
> if (a == 5) \
> do_this(b, c); \
> - } while (0)
> + })
When giving two alternatives, the reader will thank you if you explain
when each should be used. In this case, the second form should be used
when the macro needs to return a value (and you can't use an inline
function for whatever reason), whereas the first form should be used
at all other times.
Cheers,
Muli
next prev parent reply other threads:[~2006-12-31 19:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-31 19:32 [PATCH] Documentation: Explain a second alternative for multi-line macros Robert P. J. Day
2006-12-31 19:45 ` Muli Ben-Yehuda [this message]
2006-12-31 19:49 ` Robert P. J. Day
2006-12-31 20:09 ` Muli Ben-Yehuda
2006-12-31 20:03 ` Randy Dunlap
2006-12-31 20:13 ` Robert P. J. Day
2007-01-01 2:40 ` Segher Boessenkool
2007-01-01 3:23 ` Randy Dunlap
2007-01-01 4:31 ` Segher Boessenkool
2007-01-01 4:30 ` Randy Dunlap
2007-01-01 15:37 ` Jan Engelhardt
2007-01-01 17:51 ` Segher Boessenkool
2007-01-01 19:11 ` Jan Engelhardt
2007-01-01 8:26 ` Robert P. J. Day
2007-01-01 14:20 ` Christoph Hellwig
2007-01-01 14:25 ` Robert P. J. Day
2007-01-01 16:14 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061231194501.GE3730@rhun.ibm.com \
--to=muli@il.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=rpjday@mindspring.com \
--cc=trivial@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox