Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ucla-cs!kona!tj From: tj@kona.cs.ucla.edu (Tom Johnson) Newsgroups: comp.sys.mac.programmer Subject: Re: THINK C Suggestions Message-ID: <39689@shemp.CS.UCLA.EDU> Date: 3 Oct 90 20:43:20 GMT References: <61078@iuvax.cs.indiana.edu> <39560@shemp.CS.UCLA.EDU> <505@skye.cs.ed.ac.uk> Sender: news@CS.UCLA.EDU Organization: UCLA Computer Science Department Lines: 59 In article <505@skye.cs.ed.ac.uk> nick@lfcs.ed.ac.uk writes: Somebody suggested: >|>>4) Add a command for assembler output, like the command-K >|>> function for compile. That way we can see what kind of code >|>> Think C is generating, so that we can decide if we need to >|>> optimize it, and so that we have something to begin optimizing >|>> with. to which I responded: >|>Yes! Yes! Yes! Yes! >|>This would be fantastic! > >I've never seen the need for assembler output from a compiler. What's >so wonderful about it? I've been programming in C for years, off and on, >and have never felt the need to see the compiler's excretions. This business >of seeing the output and hand-optimising it seems to be a singularly >pointless way of spending one's time, unless (i) speed is *absolutely* >critical in some tight loop or other, and (ii) you can't get equivalent >or better speed-ups by spending less time just working on the C code. Exactly why I would like this feature--speed is often critical and sometimes it's easier to do it in assembly. Being able to look at the generated code is also a great learning tool. > >|>I would also like to be able to compile separate code resources as part >|>of an Application project. > >This is where the THINK C philosophy doesn't really help much. CDEF's, >WIND's and so on can be patched in through jump stubs, so that the code >is part of the same project; this is good enough for development. Well, I agree that it's good enough for applications development. That's the way I do it. But I don't spend all of my time writing applications. I also write INITs and cdevs. And using jump stubs just doesn't work too well for INIT/cdev combinations, especially when something else is required, like a DRVR. I am working on an INIT which installs a DRVR (among other things) and has a cdev which changes certain settings. Dealing with three separate projects and .rsrc files can be a headache to say the least. It's not quite enough to make me want to switch to MPW, but it's close... >My modest wishes: Cmd-'/' in the debugger to zoom windows, like in the >compiler. A compiler option to open edit windows full-size and full-screen, >rather than place them in tasteful locations. And perhaps the windows could open to the last place you were editing, rather than to the beginning of the file. >Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. > nick@lfcs.ed.ac.uk !mcsun!ukc!lfcs!nick Tom -- Tom Johnson UCLA Computer Science Department 3413 Boelter Hall, Los Angeles CA 90024 (213)825-6952 Internet: tj@cs.ucla.edu