Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.c++ Subject: Re: C++Lint thingees (was: Re: Smart Pointers -- A proposed language extension) Message-ID: <1991Feb5.232514.27169@Think.COM> Date: 5 Feb 91 23:25:14 GMT References: <1991Jan30.002612.27260@xanadu.com> <3706@lupine.NCD.COM> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 43 In article purtill@morley.rutgers.edu (Mark Purtill) writes: >rfg@NCD.COM (Ron Guilmette) writes: >>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. > It also invites compiler suppliers to either not supply the >'lint'oid and/or charging more money for it (which means some users do >without). If the checking is in the standard, this is at least less >likely to happen (although I can see vendors advertising "standard >compatibility" add-on programs and rubbish like that). It is not the job of a language standard to force vendors to provide all the tools needed to implement a good programming environment. A language standard should define the language; the contract between the vendor and the user is that a program that conforms to the language spec will produce results as defined by the language spec. Market forces should be used to go further than this. If warning messages are considered a good thing, then compilers that produce lots of useful warnings should sell better than those that don't. Word of mouth, magazine reviews, etc. should be used to weed out crappy products. Even government procurements are allowed to specify requirements beyond just those in a standard. This is frequently called "quality of implementation". However, this can be taken too far. The ANSI C standard could have left many things undefined that they actually defined to result in a compiler warning. For instance, they specified that compilers must produce warnings for syntax errors. There are a few things that we have come to take for granted in compilers, and which are supported by most modern compiler-building technologies, so it is not unreasonable to specify it as part of the language. The boundary between the two areas is, of course, fuzzy. In the end, users and vendors comprising the language standardization committee will have to decide where to place it. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar