public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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.

      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).