From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>, <gdb@sourceware.org>
Subject: Re: Switch -Wunused-variable on?
Date: Tue, 24 Apr 2012 22:11:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1204242254130.19835@tp.orcam.me.uk> (raw)
In-Reply-To: <87sjfufrlr.fsf@fleche.redhat.com>
On Mon, 23 Apr 2012, Tom Tromey wrote:
> I'd say that the best approach would be to make the declarations
> conditional in the same way that the uses are.
>
> If there are a lot of problem cases with this approach, or if it makes
> the code too ugly, then maybe it would be better just not to use this
> flag.
That IMHO just asks to refrain from interspersing function bodies with
preprocessor conditionals. Lots if not all conditional stuff can be
factored out to headers or definitions elsewhere. Linux the kernel for
one has had such a policy for years now.
Example. Do not write this:
int target_frobnicate (int count);
#ifdef TARGET_NEEDS_HARD_FROBNICATION
int target_frobnicate_harder (int count, int status);
#endif
int
handle_frobnication (int count)
{
int status;
int i;
status = target_frobnicate (count);
#ifdef TARGET_NEEDS_HARD_FROBNICATION
for (i = 0; i < count; i++)
status = target_frobnicate_harder (i, status);
#endif
return status;
}
Instead write this:
int target_frobnicate (int count);
#ifdef TARGET_NEEDS_HARD_FROBNICATION
int target_frobnicate_harder (int count, int status);
#define target_needs_hard_frobnication 1
#else
#define target_needs_hard_frobnication 0
endif
int
handle_frobnication (int count)
{
int status;
int i;
status = target_frobnicate (count);
if (target_needs_hard_frobnication)
for (i = 0; i < count; i++)
status = target_frobnicate_harder (i, status);
return status;
}
-- "i" is now live in all cases and also IMHO handle_frobnication is more
readable.
Maciej
next prev parent reply other threads:[~2012-04-24 22:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-22 8:06 Sergio Durigan Junior
2012-04-22 8:23 ` Jan Kratochvil
2012-04-22 20:25 ` Sergio Durigan Junior
2012-04-22 22:25 ` Jeffrey Walton
2012-04-23 8:55 ` Jan Kratochvil
2012-04-23 14:30 ` Tom Tromey
2012-04-23 15:49 ` Sergio Durigan Junior
2012-04-23 18:02 ` Pedro Alves
2012-04-23 18:39 ` Michael Eager
2012-04-24 22:11 ` Maciej W. Rozycki [this message]
2012-04-25 7:51 ` Andreas Schwab
2012-04-25 15:57 ` Maciej W. Rozycki
2012-04-25 16:50 ` Andreas Schwab
2012-04-25 17:22 ` Maciej W. Rozycki
2012-04-25 18:13 ` Andreas Schwab
2012-04-25 18:20 ` Sterling Augustine
2012-04-25 18:52 ` Maciej W. Rozycki
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=alpine.DEB.1.10.1204242254130.19835@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=sergiodj@redhat.com \
--cc=tromey@redhat.com \
/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