Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!raeburn From: raeburn@athena.mit.edu (Ken Raeburn) Newsgroups: comp.lang.c Subject: Re: C vs. FORTRAN Message-ID: <6068@bloom-beacon.MIT.EDU> Date: 8 Jul 88 09:49:38 GMT References: <3136@phoenix.Princeton.EDU> <225800038@uxe.cso.uiuc.edu> <797@garth.UUCP> <5173@ihlpf.ATT.COM> <852@garth.UUCP> <546@philmds.UUCP> <30305@cca.CCA.COM> <872@garth.UUCP> <553@philmds.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: raeburn@athena.mit.edu (Ken Raeburn) Organization: Massachusetts Institute of Technology Lines: 70 In article <553@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <872@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >>Actually, the real discussion is why does C have such a crippled argument >>list? It is possible to pass a list of argument descriptors. The descriptor >>list can be staticcally created and the overhead is just a register load >>of a relocated address. > >What's the big deal? You can do that already in C. Just pass a list of >pointers to structs, they are equivalent to your 'descriptors'. Both Some differences here: If the compiler automatically does it, the programmer doesn't have to do the work, the source code doesn't look ugly, and the programmer isn't given the chance to screw up. The Multics PL/I compiler (well, probably all of the Multics compilers) did this sort of thing; there were calls available to get a handle on the argument descriptor vector, and (I think) include files around describing the structure and enumerating some of the possible types. I've never had to use this feature (except maybe indirectly via debuggers), but the "overhead" involved was nothing that ever concerned me; some extra space in the text section, and an instruction or two at runtime. (When a subroutine call is involved, the overhead of a register-load is probably not significant, for large procedures. If the procedure is small enough that you'd worry about it, you probably want to inline your procedure anyways.) There are times when I've wished for something like this to be available under C; even if the language doesn't use it, you could detect (probably in stack traces from core files) some cases when the wrong arguments are being passed. (Yes, I know, prototypes should help with that too. But BSD's pcc doesn't do prototypes. On the other hand, I use GNU CC -- which has a reasonable approximation of dpANS-C -- as my default compiler anyways, so I'm trying to get in the habit.) How about a family of *printf routines that can detect type mismatches? The compiler would be hard-pressed to do this if you can specify the format string at runtime.... Or, for your use in debugging incredibly hairy code with monster data structures, a pretty-printer routine which figures out what type the argument is and displays it appropriately? >About the overhead: you forgot to mention assignment to the data >elements; for instance an actual parameter that is an expression - What has this to do with the static argument descriptor list? The types will be known at compile-time; they can be stored in a static array (in the text section of the program, if feasible); only one (constant) address needs to be loaded someplace special at runtime. >C has such a crippled argument list? I find it perfectly ok if you >don't like C - that's all on your account - but if you shout 'C has bad >this - C has bad that' you should argue that; things you take for >granted could well be less self-evident for C programmers. Well, the uses I've mentioned above may or may not seem like useful features. There are a couple of other Multicians out there who may be able to describe some uses of which I may be unaware. (I would have liked to have had a few more years with Multics before ours went away. It was, from my understanding, sort of a predecessor to UNIX, or at least in development when UNIX work started, and I find a lot of things done right in Multics that some of the UNIX systems I've heard of are just getting around to thinking about maybe sorta trying to do someday soon.... Of course, it does go both ways.) > Leo. ~~ Ken Raeburn / raeburn@athena.mit.edu systems programmer MIT Project Athena