From: llewelly@xmission.com
To: Eljay Love-Jensen <eljay@adobe.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Crafting Better Source Code in C++
Date: Mon, 22 Mar 2004 04:50:00 -0000 [thread overview]
Message-ID: <s3ru10hep2h.fsf@xmission.xmission.com> (raw)
In-Reply-To: <6.0.3.0.2.20040320113752.01f82f38@iplan-mn.corp.adobe.com>
Eljay Love-Jensen <eljay@adobe.com> writes:
> Hi everyone,
>
> #define SOAPBOX
>
> I've been asked this question several times about C++ (in particular,
> GCC's C++), and I thought I'd share my thoughts.
>
> The GCC compiler has a suite of warnings which will point out
> dangerous or suspicious coding practices. By and large, I feel that
> these GCC warnings are indicative of either bad code ("bugs"! ~10% of
> the time), or poor coding practices (~90%).
>
> In either case, I think it is a worthwhile endeavor to use GCC's
> warning facilities to help improve the source code, and improve the
> portability of the source code.
>
> At a minimum, I suggest everyone ALWAYS use these flags:
> -pedantic -Wall -W
As more and more C libraries incorporate C99 features, fewer and fewer
people will be able to use -pedantic with C++ . Many real projects
will need to seperate that code which can be written with strict
conformance from that which requires non standard features, and
use appropriately different compile flags.
While we are at it, however, I suggest another warning flag: -O
:-) . Certain warnings (like 'foo unused', and 'foo may be used
before it is initialized' ) require data-flow analysis, and so are
only enabled with -On, e.g. -Wunitialized.
>
> Other flags are documented here:
> http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Warning-Options.html
>
> I use almost all the additional flags. Call me ultra-pedantic. I
> wish there was an -WALL switch, to enable all warnings (even the
> annoying ones which I disregard), just so I wouldn't have the creepy
> feeling I've missed one.
[snip]
Compile this program:
#include<iostream>
#include<ostream>
int main()
{
std::cout << "Hello World!" << std::endl;
}
with: g++ -Weffc++ -Wsystem-headers
Alternatively, try building any boost-using C++ with -Weffc++, without
-Wsystem-headers.
Personally, I think the flags not enabled by -W -Wall are only useful
in very rare circumstances.
prev parent reply other threads:[~2004-03-21 23:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-17 22:17 visibility attribute not supported?! Jeremy Kolb
2004-03-19 10:33 ` llewelly
2004-03-19 17:37 ` Jeremy Kolb
2004-03-19 20:24 ` llewelly
2004-03-20 17:54 ` new computer language with GCC Eljay Love-Jensen
2004-03-20 18:27 ` llewelly
2004-03-21 11:27 ` Eljay Love-Jensen
2004-03-21 19:50 ` Crafting Better Source Code in C++ Eljay Love-Jensen
2004-03-22 4:50 ` llewelly [this message]
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=s3ru10hep2h.fsf@xmission.xmission.com \
--to=llewelly@xmission.com \
--cc=eljay@adobe.com \
--cc=gcc-help@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).