Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP Path: utzoo!watmath!kpmartin From: kpmartin@watmath.UUCP (Kevin Martin) Newsgroups: net.lang.c Subject: How idiot-proof must CPP be? Message-ID: <9297@watmath.UUCP> Date: Fri, 5-Oct-84 14:20:01 EDT Article-I.D.: watmath.9297 Posted: Fri Oct 5 14:20:01 1984 Date-Received: Sat, 6-Oct-84 05:22:36 EDT References: <9225@watmath.UUCP> <522@wjh12.UUCP> Reply-To: kpmartin@watmath.UUCP (Kevin Martin) Organization: U of Waterloo, Ontario Lines: 36 >Kevin Martin proposes extensions to the CPP, making it a fundamentally >more powerful macro processor in several ways. I will not examine >his proposals in detail, but any consideration of them should include >a lot of thought about the really dangerous and impossible-to-read >things that could be done with them. Martin conveniently provides an >example: >> The combination of the first three features allows generation of ragged >> initialized arrays: Each row is given a name using #eval and token >> concatanation, the row is given storage class 'static', and, by switching >> to another diversion, the row pointer in the edge vector can be >> initialized to point to the row. >Heaven help us! Right now, I have an approx. 100-row ragged array manually coded with funny names (like row_23) that I would rather never have to see, nor type. Having the above capability would make this so much easier to use. >One should think very carefully before extending the CPP, because macro >semantics are extremely dangerous. And they are dangerous in a >different way than pointers. Complex usage of a powerful macro >processor such as MACRO-11 or m4 is not just hard to make readable; it >is impossible to make readable. I consider the CPP's lack of power a >feature. I agree that many uses of macros are stupid or obscure, but then, they also often improve the readability (compare getchar with its expansion!) of the program (as in the ragged-array example). >Ill-considered wish-lists can be fun; still, I would like to see >proposed features considered guilty until proven innocent, meaning that >people who propose them should make some attempt to justify them beyond >saying "Wow, look what we could do with this!" > Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall > Delft Consulting Corp. decvax!genrad!wjh12!kendall What more justification do you need than a good use for it? I would give you the actual code that 'uses' it, but it isn't worth my time to re-code to take advantage of a non-existant feature Kevin Martin, UofW Software Development Group