Path: utzoo!attcan!uunet!mcvax!cernvax!ethz!iis!heiser From: heiser@iis.UUCP (Gernot Heiser) Newsgroups: comp.lang.modula2 Subject: Re: C++ vs. Modula2 Message-ID: <729@jupiter.iis.UUCP> Date: 11 Jan 89 10:32:20 GMT References: <114700003@uxa.cso.uiuc.edu> Reply-To: heiser@iis.ethz.ch (Gernot Heiser) Organization: Integrated Systems Lab., ETH Zuerich Lines: 90 Summary: Expires: In article <114700003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes: > >Hi, > >Which language do you think will fit more purposes? >From the present perspectives, it seems that > >FORTRAN 8x for numerical computation >C++ for system and object-oriented programming >Modula 2 for general purpose and eduation > >are going to serve ninties and the first decade of the 21th century. > >1) Is C++ not appropriate for general purpose? Why? I see no reason why it shouldn't. C++ basically contains everything that Modula does, and MUCH more. Its major drawback is what is inherited from C, which makes it very easy to write terrible code. But then, bad code can be written in ANY language. 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). >2) What are the deficiencies of Modula 2 as a system programming language? In my eyes, first of all the lack of conditional compilation. Look at C code that is portable across widlely differing hardware and operating systems. GNU emacs, for example, comes in one distribution for all supported systems. To configure it for a particular hardware/operating system, one only changes a few lines (usually 1 to 3) in the configuration file and types "make". I don't see how that could reasonably be done in 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. 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. Further missing are bit manipulation operators. BITSETs provide most (or all) that is needed, but using the BITSET operators on INTEGERs or CARDINALs requires many type casts, making these manipulations both messy and unsafe. Many further deficiencies of Modula will (hopefully) be fixed in the upcoming international standard. >What I particularly want to know is: >3) Which of the two languages, Modula 2 and C++, is better suited for numerical >computation? Both have serious deficiencies here. The most serious one is probably the impossibility to pass multi dimensional arrays of vaying size to subprograms. Linearizing your matrices to be able to pass them to subprograms is a step back towards assembler code. Also very annoying for numerical computations is the lack of a real FOR statement in C/C++. (Wirth, while always complaining about C, took the same road in Oberon.) Both languages lack an exponentiation operator. C supplies a standard library function for that, Modula doesn't. Modula does not provide information on the numeric properties of the hardware (like the machine epsilon). C has standard library functions for that. Modula provides no means to switch between single and double precision depending on the hardware (e.g. using single precision on >= 48 bit hardware, double precision otherwise). C makes that easy using #define. C has a standard math library that is more extensive than what FORTRAN-77 provides. Modula has virtually nothing, the quasi-standard MathLib0 is totally insufficient. The upcoming standard may rectify that, though according to what I've seen so far there is not much hope. If we look at current (pre-ISO Modula-2, AT&T C++, FORTRAN-77), rather than future languages (i.e. ISO Modula-2, FORTRAN-8x) the disadvantages of FORTRAN far outweigh its advantages even for numerics. Currently my language of choice would be C++ in all three fields. Whether FORTRAN-8x is really better for numerics I cannot say until I used it for a while. >Thanks in advance. > Hugh gsg0384@uxa.cso.uiuc.edu -- 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