pepke@gw.scri.fsu.edu (Eric Pepke) (09/17/90)
Here is a suggested improvement for that equisite compiler, THINK C: Have a check box in the options which causes string literals to be type unsigned char * rather than char * by default. It helps if one uses unsigned char * in one's prototypes a lot. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
jcocon@hubcap.clemson.edu (james c oconnor) (09/17/90)
From article <695@sun13.scri.fsu.edu>, by pepke@gw.scri.fsu.edu (Eric Pepke): > Here is a suggested improvement for that equisite compiler, THINK C: > > Have a check box in the options which causes string literals to be type > unsigned char * rather than char * by default. It helps if one uses > unsigned char * in one's prototypes a lot. How about they improve the compiler. I scanned an article in MacTutor which showed that Think Pascal generates better code than Think C. This ought not to be. I love the environment, but I frequently write code that is pushing the speed of my machine (ray traces, etc) and every saved instruction counts. Jim
tarr-michael@cs.yale.edu (michael tarr) (09/18/90)
Here's a couple suggestions I haven't heard before: 1. multi-file searches should be able to search through files not in the project. 2. A project should have an index that lists all functions and globals and lets you click to go directly to the given item. 3. The debugger should have a search utility. 4. The debugger should be able to remember your break points and data windows. Any comments? -- * Mike Tarr The Human Neuron Project * * tarr@cs.yale.edu Department of Psychology * * "My opinions are always my own." Yale University * **************************************************************************
rbarris@orion.oac.uci.edu (Robert C. Barris) (09/18/90)
I have some ideas as well, for anyone who cares:
1. The speed of the editor I found to be surprising compared
to QUED, MPW, and Alpha, especially when just scrolling by
using the down-arrow. It was really slow! The interesting thing
was that using the arrows in the scroll-bar improved the scrolling
speed somewhat. Also, holding down one of the shift keys and
then scrolling with the down arrow (creating a big selection as a
side effect) actually went faster than scrolling by arrow key alone!
2. I wouldn't mind the editor sluggishness so much if I could just get
the compiler/make system to always keep an eye on the disk files
and check modify dates and times. It's a real pain to have to
edit a lot of stuff with QUED and then have to go through the whole
"Make... Check Disk... (whir) Go" dialog to get it to recompile th
stuff I changed. If the make facility was a little more open minded
about alternative editors, this would be really easy.
(of course, how would it then point to your error for you when it
finds one? Would this be a real use of AppleEvents someday?)
3. Borland Turbo Debugger does a good job of working backwards from
values in variables and displaying them as appropriate enums, or, in
the case of pointers to functions, actually telling you the name
of the function pointed to (as best it can). I really wish
Think C could do that. Value of var Color is "BLUE"!
4. How hard is it to use an MMU to implement hardware breakpoints like
on the 386? Apple mentioned some tool that would do something along
these lines back at the 1988 Developer's Conference and I haven'
seen or heard since. Perhaps SADE can do this?
Turbo Debugger can do this and it is the ultimate lifesaver. "Tell
me when this byte gets written with this value..."
5. I don't have version 4.0 yet, so maybe they already did this.
"Tile Windows". MPW and QUED can both do it with a single keystroke
and it saves a lot of time futzing with window layouts when you're
looking at 5 things at once
- Robsamalone@athena.mit.edu (Stuart A. Malone) (09/18/90)
In article <695@sun13.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: >Here is a suggested improvement for that equisite compiler, THINK C: > >Have a check box in the options which causes string literals to be type >unsigned char * rather than char * by default. It helps if one uses >unsigned char * in one's prototypes a lot. I second this suggestion, with one modification: that the check box should ONLY affect string literals that start with "\p...". These strings are already being handled special by the compiler. Since the whole purpose of this construct is to produce Pascal strings, the result should be of type StringPtr. (The truth is, I wouldn't care if there were NO check box. It would be fine by me to make the change unconditionally. I realize that this would break some existing code, but I'd rather have the compiler's type checking work for me, rather than against me.) --Stuart A. Malone samalone@athena.mit.edu
hammersslammers1@oxy.edu (David J. Harr) (09/18/90)
How about a feature whereby you can automatically tell the compiler where a file that is referenced in the project is located. I am working on a program with a person in Seattle and we trade projects with no object files zVloaded in. If I try and compile the project, it invariably chokes on some of the files because I have them in a slightly different location than he does. The workaround to this is to unload and reload all the files manually, but this is a REAL hassle. If there were a way to tell the compiler "Look fo file foo.c in the folder Think C:MyCSource:" or if the compiler popped up a standard file box to let you specify where the file were located, it would be a real improvement, I think. Just my $0.39 worth... David
stay@ohs.UUCP (Steve Taylor) (09/22/90)
In article <10490@hubcap.clemson.edu>, jcocon@hubcap.clemson.edu (james c oconnor) writes: > > How about they improve the compiler. I scanned an article in MacTutor which > showed that Think Pascal generates better code than Think C. How about they fix existing bugs. For example, the odd-address error that comes from Think C's string initialization using long moves (see previous postings from me and others), and the strange case of the disabled OK button (In the "build application" dialog, when the "Save as" string is empty) that still works (with the return-key) except that it crashes Think C. This is all version 4.0.1 -- Absolute Truth is on vacation, and I'm filling in. ------------------------------------------------------------------------------- Steven H. Taylor stay@ohs.uucp trACE(tm) Development, Alpine School District.
matt@MAPS.CS.CMU.EDU (Matthew Diamond) (09/25/90)
Everyone's favorite thread is back! I would like: 1) Compiler detects multiple errors-- programming a project using Class lib. on a Mac Plus is plenty painful enough. This makes it ten times worse. Even if only certain errors could be continued from, like an undeclared symbol found, it would cut down my programming time. 2) Fix the search stuff-- Make it easier to invoke. Also, if I add a new file with it's own .h file I can't search the .h file at all until I open it explicitly or I get the .c to compile! Also, when using the Class Library a LOT of files are listed. I should be able to search only my local files easily, say via a "Search Local" button. 3) Have a "rerun" button in the debugger so that I can start over again with my current breakpoints intact. Or have it generally remember breakpoints between runs (trickier). 4) It would be nice to find a procedure or file in the debugger without switching to the edit window and back. 5) Esoteria: add functions to the editor to collapse the listing into just the procedure declarations (like an outline processor), for easy navigation. Add a lint-like checker (optional use) to find unused variables/functions, suspect pointer coercions, etc. How about a built-in automatic prototype generator (yes, I know there's a stand-alone one in sumex-aim). And I know some of these have been mentioned before; just thought I'd cast my votes.. yeah, as if they aren't committed to a new design already. Matthew Diamond matt@maps.cs.cmu.edu
tim@maths.tcd.ie (Timothy Murphy) (09/28/90)
Probably all been said before, but ...
(1) Get rid of this ccommand stuff ... just parse the command line,
like everyone else.
(2) Allow 'normal' Unix/MSDos path-names with '/'s as separators,
and the file assumed to be on the current disk,
unless the contrary is stated.
(3) Upgrade to C++. Life is too short to learn 'nearly-C++'.
(But try not to get twice as slow, like Turbo-C -> Turbo-C++.
(4) Just use the 'normal' conventions for finding #include-d files.
(5) Provide a 'make' facility, in parallel to the project stuff.
In short, don't be so ****** smart, just be like everyone else.
Having said all that, THINK C is a fantastic program ... Thanks.
--
Timothy Murphy
e-mail: tim@maths.tcd.ied88-jwa@dront.nada.kth.se (Jon W{tte) (09/29/90)
In article <1990Sep28.121554.18758@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >Probably all been said before, but ... >(1) Get rid of this ccommand stuff ... just parse the command line, > like everyone else. So where does the command line come from ? >(4) Just use the 'normal' conventions for finding #include-d files. NO ! I like the way it is now ! >(5) Provide a 'make' facility, in parallel to the project stuff. Hmmm. Maybe a tool to convert a make script to a project ? >In short, don't be so ****** smart, just be like everyone else. >Having said all that, THINK C is a fantastic program ... Thanks. Well, I'll have to say that I LIKE the "smartness". How else are we to see any innovation anywhere ? h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
huntley@copper.ucs.indiana.edu (Haydn Huntley) (09/30/90)
I've been in love with Think C for three years, but there are a few things I'd love even more if they were improved... 1) Have the arrow keys be customizable, or be like MacWrite's -- with option, shift, control, and command as modifiers to make the cursor move by characters, words, line, page, or the beginning or end. 2) Have PageUp, PageDn, DeleteRight, and shift-delete work. 3) It would be nice to be able to search and replace backward, and wrap-around is sometimes useful, too. (via check boxes) 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. 5) Wildcard filename expansion in ccommand() would be nice. Also, if it would accept pathnames in Unix style (with slashes as the seperator, that might also be useful. 6) Show line numbers in the editor. There are many programming tools one can port from Unix and MS-DOS, and when they detect an error, they tell what line number it occured on. In Unix or DOS it's easy and convenient to use that information, but in Think C, it isn't very helpful, just because the editor doesn't tell what line the cursor is on. One candidate location for displaying the line number might be to the left side of the horizontal scrollbar, where some applications put the page number. 7) It would be nice if the compiler would give warnings -- just like gcc, Turbo C and Microsoft C do. The warning messages could be displayed in another window, like the linker error listing does. Additionally, it would be nice to be able to turn on and off all of the warnings as a group, as well as individually, like one can in Turbo C or gcc. Some of the warning messages might be things like pointer-integer arithmetic combination, unreferenced variables, dead code, unparenthesized assignments within the test of an if, missing prototype, etc, etc. I really like the way that Turbo C can be configured to warn about suspicious code constructs, especially type and argument mistakes. 8) It would be convenient if the project would save the debugger's settings whenever possible. For example, if a function still had the same number of lines, its breakpoints would be saved, and if it still had the displayed variables, then those would also be saved and restored. 9) It would be really nice if Think C could really check to make sure that the correct type of arguments were being passed to library and toolbox functions. Right now it only checks the size, and that isn't very helpful, because Points, longs, and the pointers to different types are all 4 bytes long! Having the MacHeaders file sure speeds things up, but catching mistakes at compile time saves alot of debugging! 10) For folks like me who like having their function calls type checked, it would be convenient if Think C had an option to generate header files. Microsoft C can do it, though it takes almost as much time as compiling the file! 11) I'd appreciate if it were possible to fix the bug in the console routines, where once you do some output, they trap *all* incoming keystrokes, even the command keys. This is not in accord the documentation on the bottom of page 166 in the Standard Libraries Reference. 12) The qsort() function could be much faster, and the version that I worked on is smaller, too! You're welcome to use it. Whew! I know that's a long list, not because Think C isn't my favorite Mac programming tool, but because I'm a bit of a perfectionist, and thus difficult to please. I love fast, intelligent, esthetically pleasing software, and when a friend introduced me to Think C 2.0, I was blown away -- I'd never dreamed that I would get to *work* in the type environment I was trying to create for users! Thanks for making such a wonderful tool, and thanks for asking us for suggestions to make it even more wonderful! --Haydn ;; ***************************************************** ;; * Haydn Huntley huntley@copper.ucs.indiana.edu * ;; *****************************************************
chaffee@reed.UUCP (Alex Chaffee) (10/01/90)
In article <61078@iuvax.cs.indiana.edu> huntley@copper.ucs.indiana.edu (Haydn Huntley) writes: > >1) Have the arrow keys be customizable, or be like MacWrite's -- > with option, shift, control, and command as modifiers to make > the cursor move by characters, words, line, page, or the > beginning or end. > >2) Have PageUp, PageDn, DeleteRight, and shift-delete work. I guess it's time for another advertisement: I wrote an INIT called Kiss that does all that, and then some. Write me for a beta copy. (I was hoping to make it "release", whatever that means, but I was using it this weekend and the cursor droppings came back...) >4) Add a command for assembler output, like the command-K > function for compile. I like this idea. MacsBug can disassemble to a file, but it requires major editing to bring it back to real assembly code. >6) Show line numbers in the editor. [...] Or just give the line number in the link window, and provide a "jump to line #" command. Or let me do that - it'd be easy to do in Kiss, but there's no reason for it now. >8) It would be convenient if the project would save the debugger's > settings whenever possible. Yes! 'Nuff said. >9) It would be really nice if Think C could really check to make sure > that the correct type of arguments were being passed to > library and toolbox functions. [...] Do you know about the MacProtos files? Somebody typed in prototypes for all the toolbox calls. I think it's on sumex. It adds a lot of time to the compile, though, even when it's precompiled. And my latest request: Allow us to "plug in" other editors, like Preditor with MPW. That way, you can concentrate on improving the best compiler in the Mac world, and unshackle it from the worst editor. >Thanks for making such a wonderful tool, and thanks for asking us for >suggestions to make it even more wonderful! Ditto. >--Haydn - Alex -- Alex Chaffee chaffee@reed.{UUCP,BITNET} Reed College, Portland OR 97202 ____________________
tj@kona.cs.ucla.edu (Tom Johnson) (10/02/90)
In article <61078@iuvax.cs.indiana.edu> huntley@copper.ucs.indiana.edu (Haydn Huntley) writes: >I've been in love with Think C for three years, but there are a few >things I'd love even more if they were improved... > >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. Yes! Yes! Yes! Yes! This would be fantastic! I would also like to be able to compile separate code resources as part of an Application project. I often use small assembly language routines (ie response routines for Gestalt or the Notification Manager), CDEFs, DRVRs etc.. within my applications. I'd love to be able to specify that this file (or group of files) should be compiled as type DRVR, for instance and included in the resource fork of the application. Thanks-- Tom -- Tom Johnson UCLA Computer Science Department 3413 Boelter Hall, Los Angeles CA 90024 (213)825-6952 Internet: tj@cs.ucla.edu
nick@vaila.cs.ed.ac.uk (Nick Rothwell) (10/02/90)
|>>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. |> |>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. |>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. 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. |>Tom Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "Now remember - and this is most important - you must think in Russian."
gurgle@well.sf.ca.us (Pete Gontier) (10/03/90)
In article <15524@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >In article <61078@iuvax.cs.indiana.edu> huntley@copper.ucs.indiana.edu (Haydn Huntley) writes: >>6) Show line numbers in the editor. [...] > >Or just give the line number in the link window, and provide a "jump to line >#" command. Or let me do that - it'd be easy to do in Kiss, but there's no >reason for it now. What I do is double-click on the name of the offending function, hit command-E, double-click on the name of the offending file, hit command-D, and then hit command-A. If it's a link error, I hit the one I want right away. >And my latest request: > > Allow us to "plug in" other editors, like Preditor with MPW. That > way, you can concentrate on improving the best compiler in the Mac > world, and unshackle it from the worst editor. Well, I hardly think it's the _worst_ editor. It's not TeachText... :-) Seriously, though, I believe Preditor has some kind of IAC INIT which allows it to transfer buffers into THINK and compile them. We have it around here, but the docs are in Louisiana... Regardless, I think this is a good idea. The editor should be completely external, if only because of the possibilities it opens up to third parties. (I'd like to see an editor that pretty-prints without leaving THINK. That would be hot.) >>Thanks for making such a wonderful tool, and thanks for asking us for >>suggestions to make it even more wonderful! > >Ditto. Ditto. This is beginning to sound like a Rush Limbaugh convention. :-) -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
morten@cs.qmw.ac.uk (Morten Ronseth) (10/03/90)
In article <505@skye.cs.ed.ac.uk> nick@lfcs.ed.ac.uk writes: >|>>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. >|> >|>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. Here at QMW, we have our own version of the Smalltalk virtual machine, called BrouHaHa. Now, some of the optimizations we use in the making of it, depend on the availability of assembler output. Sometimes, a compiler can be really stupid, have bugs or whatever, and produce wrong/unsuitable code. In several places of our virtual machine, we have to produce the *.s file and run a sed-script on it to obtain the desired result. I assure you, these optimizations *cannot* be made by just working on the C code, in-line assembley or not (the way it is now, BrouHaHa is "impossible" to port to MacOS. Not even MPW C will do the job, being what it is. No, we're waiting for GCC to come along so we can start doing a port to MacOS...). Also, I sometimes find it useful to have a look at the assembler output to see just what the compiler is up to. Believe it or not, this can be a useful debugging tool. >Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. > nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick >~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ > "Now remember - and this is most important - you must think in Russian." Morten. -- ==================================================================== Morten Lerskau Ronseth UUCP: morten@qmw-cs.uucp Dept. of Computer Science JANET: morten@uk.ac.qmw.cs Queen Mary and Westfield College ARPA: morten%qmw.cs@ucl-cs.arpa Mile End Road Easylink: 19019285 London E1 4NS Tlf: 071 975 5220/31/47 England. Dept. fax: 081 980 6533
tj@kona.cs.ucla.edu (Tom Johnson) (10/04/90)
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 <Atlantic Ocean>!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
bruce@logic.dsg.ti.com (Bruce Florman (BFLM)) (10/04/90)
I'm afraid that I've joined this conversation in the middle, so I
apologize if any of this has already been mentioned.
A few things that I think would be convenient, although there are
obvious ways to work around their absence:
1. Add the ability to #define symbols from the projects options dialog
in the same way that you can you can set compile-time variables in
Think Pascal.
2. Predefine the symbols MC68000 and macintosh as well as THINK_C.
3. If the "Macsbug Symbols", "68020" or "68881" code generation options
are checked, define the symbols MACSBUG, MC6820 or M68881
respectively.
Cheers,
Bruce Flormantim@maths.tcd.ie (Timothy Murphy) (10/05/90)
In <20912@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >>>Thanks for making such a wonderful tool, and thanks for asking us for >>>suggestions to make it even more wonderful! >> >>Ditto. >Ditto. This is beginning to sound like a Rush Limbaugh convention. :-) What I find interesting in this discussion is that nearly everyone seems to want *more* 'Macky' features, while I want *less*. I'd like just to sit at my Mac, and 'make' a program the same was as on Unix. Maybe it was pretty clever of Symantec to reasonably satisfy both sets of clients. I thought I'd run into problems with big programs in THINK C, but I haven't done (yet?). I suppose some day I'll have to get round to the Toolbox, but the sheer weight of 'Inside Mac' and 'Mac Revealed' puts me off. I do doubt though if it's worth it (for a non-Macnik) to get into THINK C's classes. Can I be pretty sure that THINK C will develop into C++, and that these classes will be still usable then? -- Timothy Murphy e-mail: tim@maths.tcd.ie
esink@turia.dit.upm.es (Eric Wayne Sink) (10/05/90)
Something else I would like to see in Think C is the ability to compile code with more than 32k of globals. Also, how about a curses library. IMHO, Think C is already a pretty good tool for porting of UNIX-ish software - I'd just like to see it get better. Eric W. Sink Universidad Politecnica de Madrid Departamento de Telematica esink@turia.dit.upm.es
gurgle@well.sf.ca.us (Pete Gontier) (10/07/90)
It occurs to me that one of the things we're always whining about at Kiwi is type-checking. We have one poor guy who's an assembly/forth afficianado (did lots of work for the military, y'see), and what people like him would like to see is a four-byte data type like THINK Pascal's "univ" type. Come to think of it, I think I'd like that as well. The prototypes for the __TrapAddress calls would be one good place to put "univ"... -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
russotto@eng.umd.edu (Matthew T. Russotto) (10/07/90)
In article <1990Oct5.151257.26488@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >>Ditto. This is beginning to sound like a Rush Limbaugh convention. :-) > >What I find interesting in this discussion >is that nearly everyone seems to want *more* 'Macky' features, >while I want *less*. >I'd like just to sit at my Mac, >and 'make' a program the same was as on Unix. I think you are using the wrong development system for this sort of thing-- try using (horrors!) MPW C. I think there's even a version of Real Unix Make (or Gnu Make) for it. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
andwi@ida.liu.se (Andreas Wickberg) (10/08/90)
In article <20912@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >What I do is double-click on the name of the offending function, hit command-E, >double-click on the name of the offending file, hit command-D, and then hit >command-A. If it's a link error, I hit the one I want right away. Or even simpler: command-double-click on the function.
palmer@nntp-server.caltech.edu (David Palmer) (10/08/90)
Here's a suggestion for the next 'Think C'. Allow the operator '->>' to dereference handles, just as '->' dereferences pointers. This, of course, is non-standard, and so there should be a 'preferences' item to disallow it, but it would make things much more pleasant. (The reason why '->>' should be used instead of '-->' is because it shows up better, and it would not be parsed as a post-decrement greater-than combination.) -- David Palmer palmer@gap.cco.caltech.edu ...rutgers!cit-vax!gap.cco.caltech.edu!palmer I have the power to cloud men's minds -- or at least my own.
russotto@eng.umd.edu (Matthew T. Russotto) (10/09/90)
In article <1990Oct8.154744.15837@nntp-server.caltech.edu> palmer@nntp-server.caltech.edu (David Palmer) writes: >Here's a suggestion for the next 'Think C'. Allow the operator '->>' to >dereference handles, just as '->' dereferences pointers. > >This, of course, is non-standard, and so there >should be a 'preferences' item to disallow it, but it would make things >much more pleasant. > >(The reason why '->>' should be used instead of '-->' is because it >shows up better, and it would not be parsed as a post-decrement >greater-than combination.) No, instead as minus shift right. You can't win. If you make a smart compiler, you can recognize handles to structs and add the extra de-reference automagically-- I'd like to see that (in both THINK and MPW.) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
deadman@garnet.berkeley.edu (Ben Haller) (10/09/90)
In article <1990Oct9.020415.16763@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: > In article <1990Oct8.154744.15837@nntp-server.caltech.edu> > palmer@nntp-server.caltech.edu (David Palmer) writes: > >> Here's a suggestion for the next 'Think C'. Allow the operator '->>' to >> dereference handles, just as '->' dereferences pointers. > > No, instead as minus shift right. I can't think of any situation in C where ->> would be a meaningful construct. Minus shift right is not legal - you need an operand in there. Minus and shift right are both binary operators (sure, minus is unary too, but then its operand comes after the '-'). > If you make a smart compiler, you can recognize handles to structs and > add the extra de-reference automagically-- I'd like to see that Myself, I think both of these are very bad ideas for several reasons. I'll deal with the ->> first... This one has an initial attraction. But language design is very tricky. I wouldn't want this implemented unless I was *sure* that it didn't introduce any lexical ambiguity at all into the language. This is not such a simple thing to be sure of. I don't *think* it does, but do I *know*? And to be sure of this in C++, with operator overloading, is even harder, it seems to me. If there were any lexical ambiguity, either certain C constructs would be less functional than they were, or the ->> operation would only work sometimes, or something. It would be bad, and it would cause K&R and ANSI-correct programs to compile incorrectly or at least produce compiler errors unless it were done very carefully. There's a good reason why language design is considered hard. To implement a feature like this on a whim is a very poor idea. Now for having the compiler automagically double-dereference handles if it seems like what the programmer wants. First of all, I think this is a terrible idea just because it would make handles virtually identical, in the programming view, to pointers. Once you never have to double-dereference, you tend to forget that the thing *is* a handle, and you start treating it like a pointer. Then you either end up with memory moving out from under you and creating crashes, or you end up with a log-jammed heap. It's very good to keep the programmer aware of what's happening at a low level. If this isn't true, why not just make pointers dereference automagically too? If you have a pointer to a structure, just use the '.' operator to reference the structure elements. But this is a bad idea for the same reason: it makes a *big* difference whether you're using a structure, a pointer to struct or a handle to struct. If you make the usage of all of these similar, programmer errors will increase drastically. Lord knows there's enough memory errors out there without that... Also, as with the ->> construct, I'm not at all sure that you wouldn't lose some constructs that currently work. Again, I can't think of any, but I'm not a language designer, and I have much too much respect for Kernighan, Ritchie and Stroustrup to think that I can be sure of something like that. Now for both of them at once. I think they're bad because, first of all, they're nonstandard. If every compiler in the world had its own neat little "improvements", it would become meaningless to even talk about the C language. Having one universal language is very good, and it's one of the best things about the new ANSI standard for C. Second of all (this sort of ties in with the first, but it's somewhat of a separate issue), they're non-portable. Either you use them, in which case your programs can't be ported to another compiler (even on the same machine...) without going through and rewriting. Or you don't use them, in which case why have them (slightly) slowing down the compilation, clogging up the preferences dialog and adding K to the compiler? Myself, I don't know what I'll be doing five years down the road with the code I write today. I may be running it on machines that haven't been invented yet. I don't want to write machine-specific code any more than I have to, much less compiler-specific code... I think this thread should be limited to compiler features, user interface, etc. I think language design should be left to those with many degrees (or just much knowledge, often possible without many degrees :->) and a lot of experience. To try to remake C into your "dream language" is a really bad idea. Who knows? The folks who do THINK C and MPW might actually be listening, and they might actually implement these ideas, and we don't want to be sorry if that happens... -Ben Haller (deadman@garnet.berkeley.edu) "But it's all right, it's all right / For we've lived so well so long Still, when I think of the road we're traveling on I wonder what's gone wrong..." -Paul Simon, _American Tune_
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/09/90)
russotto@eng.umd.edu (Matthew T. Russotto) writes: >>(The reason why '->>' should be used instead of '-->' is because it >>shows up better, and it would not be parsed as a post-decrement >>greater-than combination.) > >No, instead as minus shift right. You can't win. Nope, the rule for C, known as the "maximal munch" rule, is that the lexer tries, from left to right, to grab as many characters as possible for the one token. So "->>" becomes "->" ">". Since these are both always binary, it's always a syntax error currently. (However, I think language extensions like the one proposed here are usually a mistake.)
hawley@adobe.COM (Steve Hawley) (10/10/90)
In article <1990Oct9.020415.16763@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1990Oct8.154744.15837@nntp-server.caltech.edu> palmer@nntp-server.caltech.edu (David Palmer) writes: >>Here's a suggestion for the next 'Think C'. Allow the operator '->>' to >>dereference handles, just as '->' dereferences pointers. ... >>(The reason why '->>' should be used instead of '-->' is because it >>shows up better, and it would not be parsed as a post-decrement >>greater-than combination.) >No, instead as minus shift right. You can't win. If you make a smart >compiler, you can recognize handles to structs and add the extra de-reference >automagically-- I'd like to see that (in both THINK and MPW.) Why can't you win? Is -> interpretted as "negative greater than"? Nope. So why should ->> cause any problems? It should be recogized correctly by the tokenizer in the scanner. This why you can write expressions like: --a---=--a-----a--; and know that it will be interpretted as: --a-- -= --a-- - --a--; Since the scanner matches the largest token. Something gross, like: a-->>=4; Would be tokenized as a-- >>= 4; If you offer the token ->> shouldn't you also offer the tokens ->>> and ->>>> and ->>>>> and ->>>>>> and ->>>>>>> etc? I thought that's what you got from (*******foo).bar... Your parser just gets ugly (uglier?). I, personally, am not for it. Is there any significant win in the coding? Admittedly, the Mac uses handles fairly frequently, but I can't see what sort of win you'd be getting from it in the code generation (especially in Think C which has no real optimizing pass). Steve Hawley hawley@adobe.com -- "I'm sick and tired of being told that ordinary decent people are fed up with being sick and tired. I know I'm certainly not, and I'm sick and tired of begin told that I am." -Monty Python
fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000) (10/10/90)
palmer@nntp-server.caltech.edu (David Palmer) writes: >Here's a suggestion for the next 'Think C'. Allow the operator '->>' to >dereference handles, just as '->' dereferences pointers. You should be able to use standard C syntax just as easily for this. If 'p' is a pointer to a structure that has a member 'x', then 'p->x' references the member. If 'h' is a handle to the structure, then '(*h)->x' references the member. What's so hard about this? I'd rather stick with standard syntax whenever possible. -- Frank Owen (fjo@mtcchi.uucp) 708-305-3182 Memorex-Telex Corporation Indian Hill Court 1000 E. Warrenville Rd. RM 1A315 Naperville, Il 60563
ech@cbnewsk.att.com (ned.horvath) (10/10/90)
From article <1990Oct9.020415.16763@eng.umd.edu>, by russotto@eng.umd.edu (Matthew T. Russotto): > ...If you make a smart > compiler, you can recognize handles to structs and add the extra de-reference > automagically-- I'd like to see that (in both THINK and MPW.) I would NOT. A handle to a purgable object -- resources are the typical case -- has to be checked before use: if (*thud) LoadResource (thud); HNoPurge (thud); /* use it */ HPurge (thud); and blurring the distinction between handles and pointers is hardly helpful. It could be argued that (*thud).member should be different from thud->member, but those two have been equivalent since the original K&R book. =Ned Horvath=
minich@d.cs.okstate.edu (Robert Minich) (10/10/90)
palmer@nntp-server.caltech.edu (David Palmer) writes: Here's a suggestion for the next 'Think C'. Allow the operator '->>' to dereference handles, just as '->' dereferences pointers. by fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000): | You should be able to use standard C syntax just as easily for this. | If 'p' is a pointer to a structure that has a member 'x', then | 'p->x' references the member. If 'h' is a handle to the structure, | then '(*h)->x' references the member. | | What's so hard about this? I'd rather stick with standard syntax whenever | possible. Your argument (except for supporting a standard) is completely bunk. If nothing is so hard about (*p)->x then why not (*p).x instead of p->x ??? What's so hard about THIS? Personally, I tend to end up with a ton a parenthesis and adding a couple more often makes it harder to understand but that's C for you. Make's me want to go back to Pascal at times (no often, though) (*object_ptr)->object_field (*((Handle *)(&(myPtr))))->field is equivalent to object_ptr^^.object_field Handle(@myPtr)^^field Of course the second part is rather dumb, but it demonstates the point. Now add a couple more typecasts in there and try your luck at figuring out you forgot a dereference and the C compiler didn't mind a bit. :-) -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| A fanatic is one who sticks to |=(___)= | minich@d.cs.okstate.edu | his guns -- whether they are | U | - Ackphtth | loaded or not.
russotto@eng.umd.edu (Matthew T. Russotto) (10/11/90)
In article <1990Oct9.171921.29529@mtcchi.uucp> fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000) writes: >'p->x' references the member. If 'h' is a handle to the structure, >then '(*h)->x' references the member. > >What's so hard about this? I'd rather stick with standard syntax whenever >possible. You start getting lisplike expressions like (*(*(*thegdev)->gdPMap)->pmTable)->ctTable[i], where thegdev->>gdPMap->>pmTable->>ctTable[i]; is much easier to write and to read. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gft_robert@gsbacd.uchicago.edu (10/11/90)
------ In article <1990Oct9.020415.16763@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes... [...] >No, instead as minus shift right. You can't win. If you make a smart >compiler, you can recognize handles to structs and add the extra de-reference >automagically-- I'd like to see that (in both THINK and MPW.) No no no. The compiler should not be doing any of this sort of stuff behind your back. POINTER != HANDLE, therefore you should not be able to use a handle in the same way lexically as a pointer. As someone pointed out previously, if you let the compiler "add the extra de-reference automagically" with handles, then why not with pointers, and have myPtr->myField become myPtr.myField? Because it's confusing, and you forget you have a pointer. Similarly with handles. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
CXT105@psuvm.psu.edu (Christopher Tate) (10/11/90)
A better solution to this "problem" (that is, trying to get C to automagically
dereference repeated handle references for speed) is not to extend C's
operator set (which brings up all those nasty problems of parsing that
people have been screaming about recently :) -- instead, why not just
extend C to have a construct similar to Pascal's WITH statement?
Personally, I find this one of the most glaring omissions in C. It's
pretty icky to have to type 17 lines of "(**myHandle).whatever = something;"
instead of a nice pretty "WITH myHandle^^ do begin....end." And, since
it's a bracketed construct, C has an easy time figuring out when to do
the dereferencing.
Maybe we should move this discussion to comp.lang.c, where it belongs....
-------
Christopher Tate | "The soldier came knocking upon the Queen's door;
| He said 'I am not fighting for you anymore....'"
cxt105@psuvm.psu.edu |
cxt105@psuvm.bitnet | -- Suzanne Vegamorse@currituck.cs.unc.edu (Bryan Morse) (10/12/90)
>Maybe we should move this discussion to comp.lang.c, where it belongs....
No, it should stay here (if anywhere). If you want to discuss the general
question of a WHEN type construct in C, then yes, go there. But since we
are, in general, discussing a problem unique (???) to the Mac, it would
not be welcome there. Do you know what it's like to read comp.lang.c and
here people repeatedly ask why they can't get their near and far pointers
working correctly? Arrgh!
The general question is: how do you efficiently (using C notation)
double-dereference handles and access structure members, especially
when chaining handle dereferences?
This is a question that I think is a serious one and deserves discussion.
I (for one) do not want to:
1. Modify C
2. Have the compiler do anything behind my back
3. Use a lot of silly parenthesis!!!
Is there any better way?
Bryan Morse
morse@cs.unc.eduzellers@prisoner.Eng.Sun.COM (Steve Zellers) (10/12/90)
In article <90283.224058CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >Personally, I find this one of the most glaring omissions in C. It's >pretty icky to have to type 17 lines of "(**myHandle).whatever = something;" >instead of a nice pretty "WITH myHandle^^ do begin....end." And, since >it's a bracketed construct, C has an easy time figuring out when to do >the dereferencing. C doesn't have this, because C requires the programmer to do most of his optimizations... (You can't move memory from within a with mumble^^ either) Consider: { (**(**onehandle).somethingotherhandle).mumblefrotz[0] = 42; (**(**onehandle).somethingotherhandle).mumblefrotz[1] = 18; } Well, if you REALLY NEED a with, then: { #define WITH (**(**onehandle).somethingotherhandle) WITH.mumblefrotz[0] = 42; WITH.mumblefrotz[1] = 18; #undef WITH } But you're programming in C for a reason, right? { reg mumbleptr pmum = (**(**onehandle).somethingotherhandle).mumblefrotz; *pmum++ = 42; *pmum = 18; } This will generate better code than THINK or MPW pascal by the way. If you like things 'automagic' and hidden from you, by all means, keep using pascal. It's not C's purpose. I've seen/written a lot of pascal that used WITH's, but it really doesn't help much, accept in the simplest cases. (My boss used to bitch me out for assigning temporary pointers in my pascal code - but how else are you supposed to compare disparate elements of some heavily dereferenced structure? You can't 'with' them both...) Ooops, I'm raving. Nevermind. >Maybe we should move this discussion to comp.lang.c, where it belongs.... They might laugh. -- ------------------------------------------------------------------------ Steve Zellers zellers@prisoner.sun.com "All you slimy fruitcakes in San Fransisco are going to find out how to get to 180 and the letter 'G'. I repeat, there is No Other Possibility."
fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000) (10/12/90)
minich@d.cs.okstate.edu (Robert Minich) writes: >Your argument (except for supporting a standard) is completely bunk. If >nothing is so hard about > (*p)->x >then why not > (*p).x instead of p->x >??? What's so hard about THIS? Personally, I tend to end up with a ton a >parenthesis and adding a couple more often makes it harder to understand >but that's C for you. Make's me want to go back to Pascal at times (no >often, though) > (*object_ptr)->object_field > (*((Handle *)(&(myPtr))))->field >is equivalent to > object_ptr^^.object_field > Handle(@myPtr)^^field >Of course the second part is rather dumb. Yes, it is. Using your examples, the "improved" syntax would yield: object_ptr->>object_field ((Handle *)(&(myPtr)))->>field I don't find this THAT much better. >Now add a couple more typecasts in there and try your luck at figuring >out you forgot a dereference and the C compiler didn't mind a bit. :-) Actually, the C compiler usually DOES mind if you forget a dereference. If you say (object_ptr)->object_field, you will get a compile error, as object_field is not a member of what object_ptr points to. O.K. I'll admit that sometimes it's a bit more difficult in C, but unless there is a language feature missing (like those added with C++), I think it's a bit late to be changing the language. -- Frank Owen (fjo@mtcchi.uucp) 708-305-3182 Memorex-Telex Corporation Indian Hill Court 1000 E. Warrenville Rd. RM 1A315 Naperville, Il 60563
iand@mullian.ee.mu.OZ.AU (Ian Robert DOBSON) (10/12/90)
One thing that's always annoyed me when using THINK C is the manner in which errors are reported. If a source file has a number of compile-time errors, the compilation process must be performed several times as a single error will stop compilation without checking the rest of the file. A much better system would be to report all errors in, say, an Errors window BEFORE ABORTING the compilation. This would save much time when, as is often the case, a large header file is included and a large chunk of code compiled before the buggy function is reached. All of this compilation time must be performed for each error. Ian R. Dobson Department of Electrical Engineering University of Melbourne iand@mullian.ee.mu.oz.AU
minow@mountn.dec.com (Martin Minow) (10/13/90)
In article <16704@thorin.cs.unc.edu> morse@currituck.cs.unc.edu (Bryan Morse) writes: >The general question is: how do you efficiently (using C notation) >double-dereference handles and access structure members, especially >when chaining handle dereferences? Define your handle-based structures as follows: typedef struct Mumble { int mumble; } MumbleRec, *MumblePtr, **MumbleHdl; /* * The MumbleRec is always accessed using the * mumbleHandle local variable. Thus, any * element in the structure may be accessed * using the following macro. */ #define MBL (**mumbleHandle) Now, your subroutine is just void IncrementMumble( register MumbleHdl mumbleHandle ) { ++MBL.mumble; } It's that simple. Martin Minow minow@bolt.enet.dec.com
tim@maths.tcd.ie (Timothy Murphy) (10/14/90)
In <1990Oct6.193731.24012@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1990Oct5.151257.26488@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >>What I find interesting in this discussion >>is that nearly everyone seems to want *more* 'Macky' features, >>while I want *less*. >>I'd like just to sit at my Mac, >>and 'make' a program the same was as on Unix. >I think you are using the wrong development system for this sort of thing-- >try using (horrors!) MPW C. I think there's even a version of Real Unix Make >(or Gnu Make) for it. Don't get me wrong -- I love THINK C. I've tried MPW, and am not enamoured of it. In any case, I teach C to some 70 Maths students, to each of whom Apple in their bottomless wisdom and generosity gave a Mac Plus (with 20MB disc). And then Symantec compounded the glory by allowing us to give them all THINK C. But as well as the 70 MACpeople, there are 70 other students in the class using Unix. So the differences between THINK C and cc are constantly highlighted. Now I think the MAC GUI, etc, is a really great intellectual achievement. And I can see that special methods are required to program it. But I feel the MACpeople are often trying to be different just for difference' sake. (I don't think it is the old thing of trying to lock the user into one manufacturer's equipment.) I mean just simple things, like calling directories 'folders'. Maybe I'm in a small minority, in not wanting to be locked into the MACworld completely. But I'd just plead with you all (and Symantec in particular) to remember us half-hearted ones. For example, the Project stuff is pretty weird, let's face it. There's the same sort of thing in Turbo-C, but at least one can avoid it there, if one wishes. Incidentally, last week I was compiling the same program -- TeX -- on a MacPlus with THINK C, and on a 386 with the new Turbo-C (Turbo-C++), and the MacPlus won by quite a good margin! And in the end, it is the compiler that matters, not the bells and whistles. -- Timothy Murphy e-mail: tim@maths.tcd.ie
oster@well.sf.ca.us (David Phillip Oster) (10/14/90)
In article <90283.224058CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >instead, why not just >extend C to have a construct similar to Pascal's WITH statement? Also, error reporting in THINK C. 1.) WITH statement. Don't kid yourself. you can write: register StructPtr myP; myP = *myHandle; myP->field1 = foo; myP->field2 = fum; ... Which is identical code to what the WITH statement generates anyway. But, it has these two colossal advantages: a.) it is explicit, you can see at a glance what things are fields of a handle and what things are variables. WITH statements generally make for code that will take you hours of puzzling out when you look at it next year. b.) it is explicit, you can see at a glance that myP->foo is a field in a structure, not a variable, and if you say something like: myP->width = StringWidth(myP->name); you can bet that it will crash because the function call will shift the heap and myP will dangle. WITH statements make it easier to forget that handles on the Mac can move, if they are not locked, depending on what function you call. (I would agree to add a WITH statement if it could be implemented in the EDITOR, so that I could choose on a case by case basis to see the full names of the fields or just the short names, depending on how well I remembered _that_ specific use.) 2.) Don't fool yourself. The reason THINK C stops at the first error is because if it were to continue the parse, it would need error recovery code. Most parsers are measurably slowed done by the presence of error recovery code even if they don't actually hit any errors (the stack frames in the parser get larger.) I want THINK C to compile correct code as fast as possible, since it compiles correct code so much more frequently than it compiles erroneous code. 3.) What I want is a mode like require prototypes, that instead produces a comile error every time it hits a statement that would need a cast if prototypes were turned off. For example: double sine(double); /* the presence of this prototype */ sine(3); /* should produce an error here, so I can edit it to: */ sine((double) 3); That way, I could turn on prototypes ONCE, add my casts, and then turn them off and get faster compiles. Since this is a fundamental flaw in the current C standard, I am unlikely to get my wish. -- -- David Phillip Oster - Note new signature. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
fxcmh@acad3.fai.alaska.edu (Chris Hartman) (10/15/90)
Two easy (I think) and very minor Think C improvements:
1) How about hilighed text using the user selected hilite color
(instead of black)?
2) This from a friend, but I agree: Allowing the user to change the
color of text in the editor. Even just the eight regular quickdraw colors
would be helpful here. This would be an easy way to make sections of code
stand out.
--
-------------------------------------------------------------------------------
| Chris Hartman INTERNET: fxcmh@acad3.fai.alaska.edu |
| Academic Computing BITNET: FXCMH@ALASKA (use this if possible) |
| University of AK, Fairbanks SNAIL: P.O. Box 901073; Fairbanks, AK 99775 |
| *********** Nobody ever said being a math major was FUN! *****************|
-------------------------------------------------------------------------------rnpantos@watdragon.waterloo.edu (Roger Pantos) (10/15/90)
(I haven't seen this mentioned yet, apologies if it has been) : Here is a simple addition to Think C that would make life easier for those of us who insist on using QUED/M, Alpha, Preditor, uEmacs, etc. (i.e. _real_ editors :-) : When "Running" the project, check the modification dates on the source files, and re-compile any that are later than when the project was last compiled. In addition, make it a user option to similarly recompile all sources with header dependencies when the header has changed. This bring us a little closer to (my opinion) the ideal Think C setup: o With only the project window open in TC, you save your source (in QUED or whatever), switch to TC and "Run". o TC (naturally :-) finds a compile-time error, and puts up a MODELESS dialog telling you about it. o Since you've got "External Editor" checked in project options, instead of opening the source and moving to the error, TC sends an AppleEvent to the editor, and _it_ moves to the right line. o you switch back out to the editor, fix the bug, re-save, and re-enter TC. You run the program again, which causes the error dialog (still up) to go away. o Any more bugs, go back to step 2 until the program runs. This is obviously not going to be work until System 7, when AppleEvents are supported. (It also requires MultiFinder, but that's mandatory in System 7.) But if Think C worked that way, it would make me, at least, very happy. (There is also the opinion that TC should find all the errors, and open a window in the editor with a list. This would be nice, but if it would kill TC's compile speed, which some have suggested, then I could live without it.) cheers --- Roger Pantos rnpantos@watdragon.waterloo.edu 4A AM Hell :-) "The power of accurate observation is often called cynicism by those who do not possess it." -- George Bernard Shaw
Jim.Lynch@f444.n161.z1.FIDONET.ORG (Jim Lynch) (11/10/90)
Hi, I'm new here but here's my suggestions:
1) have Think C work more like Turbo C: if it detects errors/warnings in the
files, it keeps compiling it until the end of the file that the error was in
(or until too many errors) and allows you to select an error which will take
you to the point in the source where it occured. Also, Think C says 'Syntax
Error' too much. I want to know WHICH syntax rule was violated.
2) Turbo C remembers the debug settings (i.e., what vars are being watched,
etc). Think C is great but there's room to improve it without making it too
complex.
3) Please let me use microEMACS and interface to it in such a way that it
would go to that editor when errors occur. MicroEMACS is capable of this, I
believe.
--
Jim Lynch - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!161!444!Jim.Lynch
INTERNET: Jim.Lynch@f444.n161.z1.FIDONET.ORG