Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers -- A proposed language extension
Message-ID: <63746@brunix.UUCP>
Date: 5 Feb 91 15:49:52 GMT
References: <TOM.91Jan21083134@hcx2.ssd.csd.harris.com> <3452@lupine.NCD.COM> <1991Jan30.002612.27260@xanadu.com> <3706@lupine.NCD.COM>
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 40

In article <3706@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
| Type checking, as well as numerous other sorts of checking for "correctness"
| of C or C++ programs *may* be incorporated into a tool which you don't
| call a "compiler", however that is often a foolish implementation
| technique.
| 
| I consider it to be a fundamental part of the job of a "compiler" to
| perform a good deal of "checking" on the programs (or sub-hunks of
| programs) that I feed it.  Placing some of the checking into a separate
| tool is like inviting somebody to write crappy code.  If you don't
| believe that, try running lint on some big hunks of code where the
| original developer decided not to be bothered with trivia like using
| lint during the initial development.  Most likely you will be horrified
| by what you find.

I'll be presenting a paper at the USENIX C++ conference in April on the
kinds of likely programming errors that could (and I believe should) be
detected by an as-yet-fictitious lint++.  Moises Lejter is a coauthor of
the paper.  We list a dozen or so candidate errors for detection, show that
they can be efficiently detected, and argue that a tool for doing such
detection should be distinct from a compiler.

The primary impetetus for this last point is that a lint++ could look for
things far afield from the usual domain of a compiler.  For example, a
lint++ could read special comments that say "this virtual function should
*always* be redefined in any derived class, no matter how far down the
inheritance hierarchy".  This would be useful for the following member
function:

    const char * className() const;  // returns the name of the class

I don't think you want your compiler checking for the enforcement of such
constraints.  At the same time, I think it's very useful to be able to
state such constraints and to have violations detected by some tool.

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."