Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!csource!Clem.Clarke From: Clem.Clarke@csource.oz.au (Clem Clarke) Newsgroups: comp.lang.c++ Subject: Re: Inheritance vs. Composition Message-ID: <89.25E5388A@csource.oz.au> Date: 22 Feb 90 14:05:45 GMT Organization: Unique Computing Pty Limited Lines: 177 In article <12029@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: > allowed to use composition with nameless members, or if a member could > be identified by any unambiguous path to it, like in PL/1. PG> Did PL/1 do that? It's been so long since I used that PG> language -- over fifteen years I guess -- I've forgotten PG> most everything about it. PL/1 has been ragged so hard over PG> the years, it seems strange to hear one of its features PG> mentioned in a positive way. IMHO PL/I is one of the most underated programming languages ever written. I have used it for application programs and system programming since its very first version. I have used on CPM and MSDOS as well. It seems to me that there is nothing that C can do that PL/I can't do, and often in a very much nicer way. I think the language design gives a more portable language than C in many cases. For example, you don't define INTs, LONG INTs etc, you specify how long you want the integer in BITS which is very portable. For example: dcl i bin fixed(15); dcl j bin fixed(31); Recently, I started to convert some PL/I code to C, and just kept on running into problems. For example, BASED storage is SUPER, but can't easily be done in C. This program is called the Jol Universal Command Language, and runs on quite a few machines now. It provides a common command language for a wide variety of machines, and soon UNIX too. I have temporarily given up converting it to C. I converted the code to Turbo Pascal, which will do just about everything PL/I will (except bit handling and a few other things). There are a number of PASCAL to C translators that will help with the conversion to C. However, most UNIX systems have PASCAL, and so it may stay in PASCAL for a while yet. PG> I seem to remember that also Cobol allows you to name a member PG> with the shortest unique path to it. This feature may be seen PG> as dangerous, as it means that modifying a data structure can PG> make a program ambiguous, but this is really unavoidable, with PG> inheritance as well. When you get used to the idea, I don't think it dangerous. It also allows you to perhaps move a variable in or out of a structure, and not change all your code. PG> As to PL/1, it actually had some *good* ideas, and some PG> ridiculous ones (exceptions as a datatype!, 22/7 resulting in PG> overflow,...). I am sorry, I do not understand you comment about "exceptions as a datatype". It does have a statement like: ON ENDFILE(input) begin; eof=true; goto end_input; end; This saves CPU time by not having to test EOF everytime you read a record. Also, I do not understand the statement 22/7 resulting in overflow. For example areas, based pointers, controlled PG> storage. Not that I think they were all appropriate at the PG> language level; for example, controlled storage is done in GNU PG> LIB C++ as the obstack class, and areas can be done in C++ 2.0 PG> with operator new overloading. On the other hand I would really PG> be happy to see based (relative) pointer support, which is PG> vital to get position independent data structures (and no, PG> "smart pointers" are not a full solution). Yes, PL/I has some very good ideas that I would LOVE to see put into C. Based storage is definitely one of them. It allows you to change a structure from say an External one to one obtained with MALLOC/ALLOC and not change any code. PASCAL has WITH POINTER^ DO, but C doesn't have any equivalent. It seems that the nearest you can get is to define a name as something like: #define based_var p->based_var And if you have a long structure, many names would have to be defined. One of the biggest ommissions in C (compared with PL/I) is, IMHO, strings. Using C's method of string handling means that the compiler (or functions) must search for the binary zero everytime strings are moved or compared. This is extremely expensive in machine time. Incidently, I have developed some C macros that simulate some of PL/I's string handling. These macros run between 5 and 24 times faster than while (*dest++=*src++); style of string copies. Both Fixed and Varying length strings are supported (including blank fill for Fixed Strings). A generic CPY macro actually copies the strings, taking into account whether the strings are C strings, PL/I or PASCAL style strings. For example: dcl (fixed100,charfixed,100,"Fixed",static); /* ^ ^ ^ ^ ^ | | | | | Variable | | | | | Name >^ | | | |< Storage Attribute | | | | ^ | Specifies | max | < Initial Value "Fixed" Fixed Length | length PL/I or Pascal | String >^ */ dcl (var100,charvar,100,"Varying",static); dcl (tempf3,charfixed,3,"333",static); dcl (tempf4,charfixed,4,"444",static); dcl (tempf5,charfixed,5,"5555",static); dcl (tempf6,charfixed,6,"666666",ext); dcl (tempv6,charvar,6,"666666",ext); int i; main() { /* Showing copies for Fixed Strings. Note: When copying long strings to short, truncation occurs. When copying short strings to long, blank fill occurs. */ cpy(tempf3,tempf4); /* Copy 3 from 4 bytes */ cpy(tempf4,tempf3); /* 4 3 */ cpy(tempf4,tempf5); /* 4 5 */ cpy(tempf6,tempf3); /* 6 3 */ cpy(tempf6,tempf5); /* 6 5 */ cpy(tempf6,tempf4); /* 6 4 */ cpy(tempf4,fixed100); /* 4 100 */ cpy(fixed100,tempf3); /* 100 from 3 */ } Cheers, Clem Clarke ---------------------------------------------------------------------- Clement V. Clarke Tel (61)-3-822-3503 CCS-JOL Pty Ltd, Fax (61)-3-882-9771 PO Box 475, Toorak, AUSTRALIA, 3142 ---------------------------------------------------------------------- --- via Silver Xpress V2.20 * Origin: Micom CBCS - Australia's Longest Running Bulletin Board -- Via Fidonet/ACSNET Gateway, Melbourne, Australia UUCP: ...!munnari!csource!Clem.Clarke FidoNet: 3:632/348 Internet: Clem.Clarke@csource.oz.au