franka@mmintl.UUCP (Frank Adams) (03/29/88)
[I have cross-posted this from comp.lang.c++ to comp.lang.c, comp.lang.ada, and comp.lang.misc, with followups directed to comp.lang.misc. Responses relating to one of these languages in particular should be directed to the appropriate place.] 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.) -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108