Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.modula2 Subject: Re: C v.s. Modula II Message-ID: <12992@mimsy.UUCP> Date: 13 Aug 88 19:30:39 GMT References: <79500004@p.cs.uiuc.edu> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 110 In article <79500004@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >... had grown used to a Modula-II like language (MESA). Mesa is considerably more useful for writing Real Programs than is Modula-II, if only because its I/O really is standard (or at least only has to deal with one O/S!). So this is more of a Mesa-vs-C: >Some of the things that really bothered me about C were: > >1. It's a one-pass-compiler language. So you must pollute your >code with multiple declarations if you make forward procedure calls. As a matter of taste, I happen to like a requirement for forward declarations that must match the later definitions. (I have an intense *dis*like for Pascal's forward, which requires omitting parameters in the actual definition.) Forward declarations help me, as a reader, know what types are attached to functions and arguments. (Of course, this is less important with better programming environments, where I can put the definition up in another window at the touch of a few keys. On the other hand, I am now at home, typing away on my H19, and there is no other window....) >2. Local changes can require non-local code restructuring. Not if you format well :-) . >Adding an else-clause can require you to restructure the {}'s. Nope: if (a) foo; /* add else here */ if (b) ... if (a) foo; else { stuff; more stuff; } if (b) ... >Often, for(;;) loops are written with *no body*, and adding additional >commands can require major restructuring of the loop. I do not understand this either. >3. Include files are hard to keep track of, nest, and structure in a >big project. Modules & Interfaces seem to work much better. Any automated scheme (Mesa's is semi-automated) tends to work better than any manual scheme. Some people have developed automated schemes for C, although since it is not handed down from on high, it can be hard to get people to use your favourite. >4. I really miss the way MESA treats records as first class types. This really is a serious problem in C. It is, however, partly fixed in the dpANS, where automatic aggregates may be initialised. There are still no generic aggregate constructors, nor is there any really decent way to deal with unions (the first-member rule is not useless but does not do anywhere near enough). >5. I miss MESA INLINE procedures. They are simpler and (often) more >efficient than C's macro expansions. Actually, they are not always simpler. What are the semantics of the static variable below?: inline int unique_integer() { static int next; return (next++); } The intended semantics are obvious, but providing exactly those semantics is not trivial, since all users of the inline function, regardless of source file, must use the same `next', which must be different from the `next' of any other inline function. (GCC, incidentally, does this right, when it does it at all. The gcc we compiled a month or two ago on a Sun broke when asked to deal with inline functions, although the code it tried to generate would have been right---if that makes any sense to you.) >6. C has no provision for callback procedures (you need nested >procedures and the right semantics for the 'display'). So data >abstraction is hindered in C. You need neither, and I personally believe that those sorts of nested variables (if not the procedures themselves) are a misfeature---they add a fair bit of expense to the calling sequence (gotta maintain them displays or static links) and account for very few actual variable accesses. Better to use (semi-)hidden pointer parameters a la C++, which also effectively gives you closures. Someone else complained about a lack of `var' parameters. Again, I think this is a very *good* thing. One of the worst problems with reading Pascal code is that every procedure and function call might potentially alter every variable argument. If I see a section of C code that reads munch(a, b, &c, d, e + 7); I can assume that it cannot change a, b, and d (unless they are arrays, arrh), while the same statement in Pascal, stripped of its warning `&', tells me no such thing. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris