Path: utzoo!attcan!uunet!dino!sharkey!mailrus!tut.cis.ohio-state.edu!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga.tech Subject: Re: Can you nest subroutines in C? Message-ID: Date: 30 Jun 89 03:12:08 GMT References: <4501@crash.cts.com> Organization: Drew University/NJIN Lines: 47 In article <4501@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes: > I do not understand why C does not support Nested routines. Perhaps > this will be added to the ANSI standard at some point in the future. The > nice thing is, backward compatability would not be an issue. But such things > happen slowly. So I guess I'll just work around the deficeincy, as this is > not something I must have to work in C. Perhaps when an optimizing M2 > compiler comes out I'll switch back to M2. They are not in C because it is difficult to implement them so that they are speed-efficient. If you look at the code generated for a sub-procedure, it usually has to do things through one additional level of indirection. I doubt that something like it will be added to ANSI C. First of all, the speed-demons will rant and rave, secondly others will claim that 99% of that can be done via separately compiled modules. Most importantly, I believe that C++ will dominate the C market by the time another ANSI C draft is written, and since C++ gives the scoping rules that you are requesting, it will not be needed. Personally, I wish there was a way to get some real good control over scope and visibility (independently of each other) in C. I think that C++ will meet my needs. DEC's Vax/VMS Pascal adds extensions that let you directly control the scope, visibility, parameter passing method, and just about everything else I can think of; and each is independently controlled. Alas, it's for VMS :-) The efficiency of all HHLs can be brought to "almost" equal if you really have a way cool optimizer (and if you are liberal about your definition of "almost" ;-). The problem is that a simple C compiler will generate much faster code than a simple Pascal compiler; hence the stereotypes of fast-C and slow-Pascal. With the momentum that C has, I doubt that many companies will dedicate enough capital to producing such a good optimizer. (I hear crowds yelling "so stick with C so your base is more efficient!") Of course, you could petition your local XJ11 ANSI member :-) > Wade. > UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!wade > ARPA: crash!pnet01!wade@nosc.mil > INET: wade@pnet01.cts.com -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University