Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mtune!mtx5c!mtx5d!mtx5a!mat From: mat@mtx5a.COM (m.terribile) Newsgroups: comp.lang.c Subject: Re: Re: Another portable code question Message-ID: <1849@mtx5a.COM> Date: Mon, 6-Jul-87 15:08:50 EDT Article-I.D.: mtx5a.1849 Posted: Mon Jul 6 15:08:50 1987 Date-Received: Fri, 10-Jul-87 06:28:48 EDT References: <16673@cca.CCA.COM> <1763@ttrdc.UUCP> Organization: AT&T Information Systems, Middletown, NJ 07748-4801. Lines: 60 > >>> There it is in a nutshell, you really don't need the * unless the function > >>> is declared int (**func)();, then you have pointer to pointer to a fun > >>> tion returning an integer. > > > >True ususally you want to pass the address of a strucuture. But what if > >you change the values of the structure in the function, and DON'T want > >to know about the changes after returning from the function???? > > Maybe I am not too familiar with the BIG frame architectures, but I am > somewhat familiar with items of the Sun/uVaxII genre on down. The issue > actually boils down to efficiency of structures and the simple fact is: > > Operations on static variables are ALWAYS faster than operations on auto > variables. No it does not, and no they are not. It does not boil down to that because the question of *what* you are pssing, and with what semantics, will not go away just because you want it to. And no, static references are not always cheaper. On the 68000, a reference to a something at a fixed address requires 2 to 4 bytes more memory and takes 2 to 4 extra clock cycles than a reference relative to an address register. > ... If you insist upon doing big structs as "auto" (stack) variables, > then there is probably not much difference in speed - both passing a > structure on the stack and copying to a local "auto" are slow. You do what you need to to get the semantics you need. If you don't need it, don't do it. > ... Secondly, MANY C compilers still do not support pushing anything other > than simple arguments on the stack. Pushing whole structures is NOT > portable in my book. Refusing to use an enhancement that became available years ago and has become as near to standard as anything else in the language is a disservice to yourself and to the people who worked to create the enhancement. > As it turns out, almost ALL efficient C compilers handle static memory > allocation much better than stack, too. So, you are not saving any REAL > memory, although swap decreases. (Use of static is REQUIRED in our Sun 3.0 > compilers here at USC, ANY auto variable over 16k-bytes in size gets lunched > on the second recursive entry. *THIS* is a nonstandard compiler bug. > It took me 2 weeks and head bashing with the also buggie dbxtool to figure > this one out. By breaking things up to <16k-bytes and using static, the > code zooms!) Arguing from bugs through bugs what can you expect except misfeatures? -- from Mole End Mark Terribile (scrape .. dig ) mtx5b!mat (Please mail to mtx5b!mat, NOT mtx5a! mat, or to mtx5a!mtx5b!mat) (mtx5b!mole-end!mat will also reach me) ,.. .,, ,,, ..,***_*.