flaps@utcs.UUCP (06/20/86)
I have just received MS C for the IBM PC/AT running MS-DOS.
The manuals, besides being poorly and sometimes inaccurately written,
encourage all sorts of stupid things. I would like to share two things
with you.
1. They have instituted a pre-processor conditional of the form
#if defined(MANIFEST_CONSTANT). Furthermore, the manual notes that
use of #ifdef is "discouraged" (though at least they support it).
Here in net.lang.c several C revision proposals have been rejected on
the grounds that they don't add enough to the language to merit the
inconvenience of a change. This change from #ifdef adds absolutely
nothing to the language!
2. The manual does not permit something of the form:
struct tag { typedeclaration value; ... };
although the compiler does. The manual requires that you actually
declare something with the struct. This is not a feasible restriction
on C and in fact MS C is not so restricted.
In other words, my complaint about MS C is that there are mindless restrictions
(in typical IBM style). The examples in the book are all stupid and unclear.
I don't know how I would learn C there if I hadn't first learned it here.
--
Alan "IBM-hater" Rosenthal
{decvax|cbosgd|linus}!ihnp4!utcs!flaps, utzoo!utcs!flapsguy@sun.UUCP (06/21/86)
> 1. They have instituted a pre-processor conditional of the form > #if defined(MANIFEST_CONSTANT). Furthermore, the manual notes that > use of #ifdef is "discouraged" (though at least they support it). > Here in net.lang.c several C revision proposals have been rejected on > the grounds that they don't add enough to the language to merit the > inconvenience of a change. Microsoft didn't institute this. John Reiser did when he was at Bell Labs. This feature has been in UNIX since Version 7, and has been documented since System V. It is also in the ANSI C draft standard. > This change from #ifdef adds absolutely nothing to the language! Wrong. You can't say #ifdef FOO || BAR to include code if FOO or BAR is defined, but you can say #if defined(FOO) || defined(BAR) This is useful, and has in fact been used in a number of programs. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
chris@umcp-cs.UUCP (Chris Torek) (06/21/86)
In article <1986Jun20.01:10:46.477@utcs.uucp> flaps@utcs.uucp (Alan J Rosenthal) writes: >1. They have instituted a pre-processor conditional of the form > #if defined(MANIFEST_CONSTANT). They have not instituted it. It has been around since V7, at the latest. It is quite useful; things like #if (defined(x) || defined(y)) && defined(z) are fairly tricky (not to mention confusing) to write without this. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ark@alice.UucP (Andrew Koenig) (06/21/86)
> 1. They have instituted a pre-processor conditional of the form > #if defined(MANIFEST_CONSTANT). Furthermore, the manual notes that > use of #ifdef is "discouraged" (though at least they support it). > Here in net.lang.c several C revision proposals have been rejected on > the grounds that they don't add enough to the language to merit the > inconvenience of a change. This change from #ifdef adds absolutely > nothing to the language! Well maybe. But Microsoft didn't invent this usage. Try it on your favorite Unix system and see for yourself.
gwyn@brl.arpa (VLD/VMB) (06/22/86)
Alan "IBM-hater" Rosenthal posted an article flaming MicroSoft C for its "stupidity" (in his opinion). While I don't much like IBM PCs, I like ignorant flames even less. Rosenthal's posting may have confused some inexperienced C programmers, so correction may be useful. In the following, lines starting with > are Rosenthal's original remarks. >The manuals, besides being poorly and sometimes inaccurately written, >encourage all sorts of stupid things. I would like to share two things >with you. > >1. They have instituted a pre-processor conditional of the form > #if defined(MANIFEST_CONSTANT). Furthermore, the manual notes that > use of #ifdef is "discouraged" (though at least they support it). > Here in net.lang.c several C revision proposals have been rejected on > the grounds that they don't add enough to the language to merit the > inconvenience of a change. This change from #ifdef adds absolutely > nothing to the language! First, this is not a MicroSoft invention. It has been in many C compilers, including UNIX PCC, for years. (Actually it is "macro name" that is tested, not just "MANIFEST_CONSTANT".) Second, having an explicit predicate does add something over #ifdef; it is more general: #if defined(BRL) && !defined(pdp11) /* I use this a lot! */ >2. The manual does not permit something of the form: > struct tag { typedeclaration value; ... }; > although the compiler does. The manual requires that you actually > declare something with the struct. This is not a feasible restriction > on C and in fact MS C is not so restricted. It's hard to make sense of this out of context, but if it precludes struct foo { int bar 123; }; as I suspect it does ("value" smacks of initializer to me), then it is a perfectly correct restriction. >In other words, my complaint about MS C is that there are mindless restrictions >(in typical IBM style). The examples in the book are all stupid and unclear. >I don't know how I would learn C there if I hadn't first learned it here. It is not clear that Rosenthal *has* learned C or even how to read manuals. One has to admit that at least one MicroSoft C user was apparently not adequately served by their documentation; not having seen it, I don't know whether the blame for that lies with MicroSoft or with the user. But the flame was certainly off the mark.
rgenter@BBN-LABS-B.ARPA (Rick Genter) (06/23/86)
Actually, the defined() preprocessor function does provide a convenience over #ifdef in one specific case: #if defined(VAX730) || defined (VAX750) || defined (VAX780) < code which is included when any of the three symbols are defined > #endif /* defined ... */ This is a royal pain to accomplish with #ifdef: #undef KLUDGE #ifdef VAX730 #define KLUDGE #endif /* def VAX730 */ #ifdef VAX750 #define KLUDGE #endif /* def VAX750 */ #ifdef VAX780 #define KLUDGE #endif /* def VAX780 */ #ifdef KLUDGE < code which is included when any of the three symbols are defined > #endif /* def KLUDGE */ Alternatively, you have to include the code three times. - Rick -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/506 rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbn-labs-b.ARPA (Internet old) linus!rgenter%BBN-LABS-B.ARPA (UUCP)
bright@dataio.UUCP (06/23/86)
In article <1986Jun20.01:10:46.477@utcs.uucp> flaps@utcs.uucp (Alan J Rosenthal) writes: >I have just received MS C for the IBM PC/AT running MS-DOS. >The manuals, besides being poorly and sometimes inaccurately written, >encourage all sorts of stupid things. >1. They have instituted a pre-processor conditional of the form > #if defined(MANIFEST_CONSTANT). Furthermore, the manual notes that > use of #ifdef is "discouraged" (though at least they support it). > Here in net.lang.c several C revision proposals have been rejected on > the grounds that they don't add enough to the language to merit the > inconvenience of a change. This change from #ifdef adds absolutely > nothing to the language! Ah, but it does add an important capability! It is very convenient to do: #if defined(abc) && defined(def) || defined(ghi) code... #endif I need this capability as I write code that is ported to as many as 8 different C compilers and machines. Of course, the feature already exists, because if an identifier is not defined it is replaced with 0 in #if expressions, but I think that's a worse kludge.
flaps@utcs.UUCP (06/26/86)
In article <1986Jun20.01:10:46.477@utcs.uucp> I write words which I have come to eat, namely that microsoft is to blame for adding #if defined(macro_name) to C and that this is a useless extension. Uncomfortably many people have pointed out to me that microsoft did not in fact make the addition and that it is in fact useful for compound conditions. In article <1566@brl-smoke.ARPA> gwyn@brl.ARPA calls me "ignorant" and observes that "It is not clear that Rosenthal *has* learned C" and seems not to understand my complaint about the manual section concerning struct declarations explained below. (The other flamers were polite.) He also explains that it is #if defined(macro_name) rather than (manifest_constant). I believe that the microsoft manual is in error here, but I forgot to check this earlier this evening. What I did check from the microsoft manual (Microsoft C Language Reference, copyright 1984, 1985 by Microsoft Corporation, document number 8416L-300-00), is their explanation of the struct declaration. On page 57 they offer the following two syntaxes for struct declarations: struct [tag] {member-declaration-list} declarator [, declarator...]; struct tag declarator [, declarator...]; Now neither one of these can generate the frequent declarations of the form: struct record { char data[80]; struct record *next; }; , as this is missing a non-optional "declarator". Almost needless to say, this ridiculous restriction is not actually enforced by the compiler. However, on page 59 there are five examples none of which involves a style similar to my struct record declaration above, so it would appear that the writers of the manual are unaware of this syntax or have ulterior motives for not writing it down. On page 55, enum declarations are defined in exactly the same way which I believe is equally erroneous. Furthermore, I believe that it would be a big mistake to remove #ifdef from the language, because it is still being widely used, and unlike the reserved word question (if you add reserved words to the language you restrict it, in a sense), removing #ifdef would allow no new programs (such as, for example, removing 'entry' would, because you could then call a variable 'entry'). -- Alan J Rosenthal {decvax|cbosgd|linus}!ihnp4!utcs!flaps, utzoo!utcs!flaps
gwyn@BRL.ARPA (VLD/VMB) (06/29/86)
If you had not called MicroSoft "stupid" I would have replied politely. Perhaps they are stupid, but your posted examples did not demonstrate that.