Path: utzoo!yunexus!spectrix!John_M From: John_M@spectrix.UUCP (John Macdonald) Newsgroups: comp.lang.misc Subject: Re: C++ enhancements Keywords: pragma Message-ID: <530@spectrix.UUCP> Date: 1 Apr 88 18:58:26 GMT Article-I.D.: spectrix.530 Posted: Fri Apr 1 13:58:26 1988 References: <2781@mmintl.UUCP> <2249424b:4311@snark.UUCP> <2789@mmintl.UUCP> Reply-To: jmm@spectrix.UUCP (John Macdonald) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 55 In article <2789@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >[...] > >In article <2249424b:4311@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >>I'll state this as a more general proposed rule for the 'what should we hack >>into C++ next' game: >> >> OPTIMIZATION HINTS SHOULD BE PROPOSED AS OPTIONAL PRAGMAS, IF AT ALL > >I have trouble with pragmas. The problem is not, perhaps, intrinsic; but it >is very much in evidence in every language where I have seen them. The >problem is that each vendor is allowed to define their own pragmas, with no >guarantee that someone else won't use the same pragma for something entirely >different. > >If pragmas are going to be used, they should be as much part of the language >standard as the syntax. A vendor may choose to follow or ignore whatever >pragmas they choose to; but *if* a pragma is not ignored, it should be used >as specified. > >To expedite the introduction of new pragmas, there should be a central >repository of pragma definitions. Compiler writers should be able to define >a new pragma, and within a few weeks have it officially recorded in the >repository. The name may not be the one requested, but the functionality >should be. (A review committee to go over the pragma and suggest >improvements is a tempting idea, but should not be permitted to slow down >the process.) You can have it both ways, if the syntax of pragma is chosen carefully. Allow statements of the two forms: pragma pragma specific Where is a "standard optional extension" that is defined by the language standard-setting body. Compiler-specific extensions are also allowed, but must be explicitly marked as such using the second format. A compiler can then choose to implement or ignore pragmas defined by other compilers (just as they can implement or ignore "standard" pragmas). If a specific pragma is supported by many other compilers, then it is a strong candidate for inclusion as a standard pragma in the next revision of the language. An additional benefit is that anyone who uses a non-standard pragma is forced to be aware that they are doing something that is not portable. Many people only read the manual for the implementation that they use, and often are not aware of whether a language feature in their implementation is part of the standard language. This could reduce the number difficulty of porting a program that was coded for local use and later discovered to be of wider utility. -- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm