Path: utzoo!attcan!uunet!mcvax!cernvax!ethz!iis!heiser From: heiser@iis.UUCP (Gernot Heiser) Newsgroups: comp.lang.modula2 Subject: Re: C++ vs. Modula-2 Message-ID: <743@jupiter.iis.UUCP> Date: 22 Jan 89 15:11:53 GMT References: <122@m2cs.naggum.se> Reply-To: heiser@iis.ethz.ch (Gernot Heiser) Organization: Integrated Systems Lab., ETH Zuerich Lines: 193 Summary: Expires: In article <122@m2cs.naggum.se> frode@m2cs.naggum.se (Frode Odegard) writes: >The point is, people won't write purely o-o in C++, because they'll use lots >of exisiting C libraries which are not exactly o-o. Granted. But people aren't going to program purely OO in Modula since the language doesn't support it at all. So, what's your point? >>C++ lacks the strict checks of module dependencies that are performed by (most) >>Modula compilers. However, in a UNIX environment (with make), the C/C++ approach >>works equally well (and is much more flexible). > >Bull! First of all, I would never use a programming language (for a project over >1000 lines) which doesn't support separate compilation of module/class definitions >and implementations. May I return that compliment? Look at the language BEFORE flaming! Fact is that - nowhere in the (current) definition of Modula-2 it is said that DEFINITION MODULES are compiled. In fact, there are compilers (e.g. the Powell compiler from DEC) that don't. - The important point is that usage of an external entity is always checked against its definition. This is the case with C++. - The strict checks using module keys as done by most Modula-2 systems is relatively save but also creates lot of overhead so that in the long run it often costs more than it buys. In a large system you cannot afford adding comments to a central DEFINITION MODULE because you would have to recompile everything. Also one would like to be able to make upward compatible changes to modules (e.g. adding procedures) without recompiling the whole system. Incidentally, this last point was solved much better by a SIMULA-67 compiler I used a lot almost 10 years ago. SIMULA does not have the notion of separate definition and implementation but the compiler would still produce a symbol file when compiling an external class. It was smart enough only to produce a new symbol file if anything really changed. Of course, this scheme could be easily incorporated into Modula, but this seems to be against the "small is beautiful" spirit. >What's the point of using an o-o language (which >C++ claims to be) if you have to update Makefiles every time class dependencies >change??? Bah! So much for the Smalltalk inheritence, right? :-) Is that your idea of OO programming? Frequently changing class dependencies? :-{ >>> What are the deficiencies of Modula-2 as a system programming language? >>In my eyes, the lack of conditional compilation. [ ... ] >Have you actually _programmed_ in Modula? Preprocessors and other utilties are >not magically built into a computer language (except maybe Lisp and Smalltalk, >where there's no border between language and environment). Yes, I have programmed in Modula, quite a bit acually. But have you ever written a large code that was to run on _many_ different architectures/operating sytems? And have you ever programmed in C++? We are not discussing how each language could be mocked up o make it more usable, rather how usable it is in its current state. And fact is, that cpp _is_ an integral part of the C/C++ languages, while this is _not_ the case with Modula. And fact is that you _can_ write portable code in C/C++ while this is virtually impossible with current (pre ISO) Modula-2. (I hope it will be possible in ISO Modula.) >>Second are address computations. Their definition in Modula is WRONG! If you >>add one to a pointer in Modula, that's one storage unit (you don't even >>know whether it's one byte or one word). in C/C++, adding one to a pointer >>to char increments the address by one byte, incrementing a pointer to int >>increments the address by sizeof(int). That's the way it should be. > >Just like ++ and -- are in C mainly because of the PDP-11 instruction set :-), and INC/DEC in Modula because of the Lilith instruction set... >The reason why Modula doesn't have +,-,DIV,REM,* defined for ADDRESS values is >that it is considered machine-specific. wrong again. These _are_ defined for ADDRESS values (check PIM2, ed.3, p 166) but, as I said before, their definition is WRONG (i.e. such that ADRESS computations are, unnecessarily, non-portable). >Modula-2 hackers know that modules which import from SYSTEM are machine/os/ >compiler-specific anyway. You see, that's the difference. Modula-2 somehow seems to convey that every program that uses low level features is by definition non-portable. But in fact you can go a long way doing low-level stuff portably if things are done right. The way address computations are defined in C _does_ allow portable use. >>Allocation of space for records (particularily alignment) is unclear in Modula. >>Operating system calls frequently return pointers to records with some operating >>system-defined layout. Mapping these on Modula records is, due to alignment, >>compiler dependent. > >It's not a big problem, really. When you do Modula-2 interfaces to OS calls, >you're operating on a low level of abstraction anyway. The data structures will >not be portable to another OS. They will however, with some usage of subrange >types (another good Modula-2 feature which C/C++ don't have) be portable from >compiler A to compiler B. We've written a very complete interface to the SunOS >system calls, and it was not difficult at all. Note that I said "compiler dependent", not OS dependent. Of course such stuff is OS specific. However, your Modula-2 SUN-OS interface will be heavily compiler dependent (I am speaking from experience). Particularly subranges are very much subject to the compiler writer's taste. Some allocate the same space as for INTEGERs, others don't. That's exactly the kind of problems you do not have in C/C++ (or only to a much lesser degree). >What's the problem? Since Wirth released the paper "revisions and amendments >to Modula-2" quite some time ago, multiple-dimension open arrays has been >_in_ the language. Sorry, but it just aint so. The "revisions and amendments to Modula-2" were published prior to the 3rd ed. of PIM2 and neither the former nor the latter contains multiple-dimension open arrays. Apparently some of Wirth's latest compiler do contain it, but at this time it can hardly be considered a standard feature. If it is going to be in the ISO standard, that's only for the better. >The library issue is being fixed once and for all in the upcoming ISO standard. >This hasn't been a huge problem for big Modula-2 projects (at least that's my >experience) because "real Modula hackers write their own libraries anyway". This also seems to be a widespread philosophy among Modula users: There are so many wheels to be re-invented, aren't there? >Standard libraries: great for text-books and classes, but some of the big >Modula projects have done everything from the compiler up to the 3,000,000-line >application in-house. What's a 3,000-line library, then? A couple of weeks of >hacking? Wrong again. A library that must support portable software needs _much_ more care in design than other code, unless you are willing to redesign it whenever you are targeting it at another host system (at the expense of modifying all the code that depends on it). And, of course some parts (or most of it, depending on how it's written) of the library need to be re-implemeted for each port. A "few weeks hacking" will only increase your problems in the long run. >Modula-2 users spent much less >time that C users digging on a low level trying to find a bug that wasn't seen >by the compiler. ... and, according to my experience, much more time in patching around compiler bugs. But that's of course not a problem with the language per se. I do agree that Modula is a much nicer, cleaner language, put particularily for large projects I would prefer C++ anytime. >I don't believe in the C culture that says"leave my hacks alone, I only run >lint on Christmas Eve". There is no more linting with C++, the compiler does its job properly. >C++ is not as good as Modula-2 for large projects, I expect, because it doesn't >support separation (by compilation, by rule, defined in the language etc.) of class >definitions and implementations. C++ is far superior to Modula-2 for large projects because it supports _real_ data abstraction, real OO programming (with inheritance not only of attributes but also of methods) and many other small things like in-line procedures, constant array parameters (without the overhead for copying) and and and... >>In the Modula-2 context, I am sure that the machine-specific vector extensions >>to the CDC Pascal/Modula-2 compiler (for the Cyber 205 & ETA-10) are not >>syntactically valid on other machines. > >If someone does non-standard Modula-2 implementations, I don't think Modula-2 >can be blamed. Compiler/machine-specific extensions to the language should be >put in SYSTEM. You didn't get the point that person was making. The point is if your standard language is not powerful enough to make use of essential hardware facilities (in this case vector hardware) than you may be FORCED to use non-standard features. But you still want to keep your programs portable which requires conditional compilation. >C hasn't got a module concept. But C++ has and we were talking about Modula-2/C++/FORTRAN >I agree. However, I'm not sure preprocessors repesent a good solution to >portability. I think it's essential. >*** FLAME := NOT FLAME; END ****** I hope I remained factual. >| Frode L. Odegard |"The world is coming to an end! Repent and| >| Modula-2 CASE Systems |rm /bin/cc" | >| NORWAY (EUROPE) | | >| Email: frode@m2cs.uu.no | | -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser