gurgle@well.sf.ca.us (Pete Gontier) (10/10/90)
I've been pooling local requests for improvements for THINK C 5, and here's the summary: o A real linker. The linker should eliminate dead code at a function level (and there should be an option to notify the user when such a thing occurred). At launch time, there should be no part of the linking process going on. There would be one kind of library if this were implemented. In this way, you could nest libraries within projects and open the libraries from inside the projects. This would clear up the problems of ownership introduced in the next suggestion, because the terminology would preclude confusion. o Project nesting. We wish we could have multiple projects open. Double- clicking on a project item in a project window should open that project. I guess there'd have to be a "master" project - the root of the project tree. How that would be accomplished I don't know. Some of it would clear up if the previous suggestion were implemented. o Multiple resource files. Projects should be capable of including more than one resource file. What we're doing here at Kiwi is generating an immense library of re-usable modules, and each module is assigned a certain resource ID range or ranges. Consequently, each module can be developed separately, with its own resource file. If THINK C could handle multiple resource files, we'd be much better off, since we'd never have to re-merge a project's resources if a module changed. o The compiler error messages should be improved. "Invalid prototype" should be changed to "Type <type> not defined." The compiler should say *which* parameter in a function call fails to match the prototype. The compiler should issue warnings (with an option to turn them on and off, and probably options for each kind of warning). Example: "foo.c: variable bar not used in function do_foo." MPW does this well. The interface for this should behave like the Link Errors window. Finally, the present method of dismissing the error alert is a pain, and so is the idea of running an INIT to fix the problem. Instead of calling Alert, write an event loop that looks for *any* key or *any* mouseDown. o We are explicitly uninterested in C++. We are perfectly able to create re-usable code with things the way they are, and we would prefer that time be spent on other things (like the linker). Do not mistake us for Luddites; we like the OOP stuff in THINK C right now. It's just that we think the next important generation in software engineering will not be C++. o Of course, we're always interested in code generation optimizations.
morse@currituck.cs.unc.edu (Bryan Morse) (10/12/90)
In article <21107@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >o Project nesting. We wish we could have multiple projects open. Double- > clicking on a project item in a project window should open that project. I > guess there'd have to be a "master" project - the root of the project tree. > How that would be accomplished I don't know. Some of it would clear up if the > previous suggestion were implemented. Amen! I like to organize common routines into separate projects and use them in larger projects. If it becomes necessary to modify or add to the sub- project, it is a real pain in 4.0. >o We are explicitly uninterested in C++. We are perfectly able to create > re-usable code with things the way they are, and we would prefer that time be > spent on other things (like the linker). Do not mistake us for Luddites; > we like the OOP stuff in THINK C right now. It's just that we think the next > important generation in software engineering will not be C++. This is what really prompted me to respond. There is more to C++ than just OOP! I personally would like to see the "better C" parts of C++ implemented in Think C as well as imitating the OOP portion of C++. This isn't flaming the above comment, just asking (begging?) Symantec to add some of the non-OOP parts of C++: - default parameters - for (int i = 0; ... ) - overloading: (very do-able) int a; float b; print(a); print(b); Of course, C++ would be nice. But until then, if we are going to take some of C++ and graft it onto C, why not include the non-OOP parts as well? Bryan Morse morse@cs.unc.edu
chaffee@reed.UUCP (Alex Chaffee) (10/16/90)
>In article <21107@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: > >>o Project nesting. We wish we could have multiple projects open. Double- >> clicking on a project item in a project window should open that project. Add another tally mark to that one... In article <16707@thorin.cs.unc.edu> morse@currituck.cs.unc.edu (Bryan Morse) writes: > I personally would like to see the "better C" parts of C++ implemented > in Think C as well as imitating the OOP portion of C++. This isn't flaming > the above comment, just asking (begging?) Symantec to add some of the non-OOP > parts of C++: > - default parameters > - for (int i = 0; ... ) > - overloading: (very do-able) > int a; > float b; > print(a); > print(b); - how about true inline functions? Come on; you've got an assembler and a compiler right there; why make us hand-assemble our inline functions into machine code? (cf. p.125) Something like inline pascal void PrOpenPage() { asm { move.l #0x10000808, -(SP) _PrGlue } } (to follow the example in the manual). Of course, I don't know C++; they probably have a better syntax for doing this. - Alex -- Alex Chaffee chaffee@reed.{UUCP,BITNET} Reed College, Portland OR 97202 ____________________
gurgle@well.sf.ca.us (Pete Gontier) (10/19/90)
Yet more suggestions gathered from among the multitudes at Kiwi... 1. The debugger should save its window positions with respect to each project. 2. The meanings of command-S and command-T should be reversed. At the moment, they are exactly opposite those of MacsBug. Very confusing. 3. There should be MacsBug symbols for all named C functions. As it is, some void functions drop out and some small functions, as well. Additionally, the names generation should be brought up to the new standard, which spells out the entire name. I believe MPW assembler generates names in this way. And, in my own interest... 4. I wish I could turn on stronger enum type checking. I want to be able to limit a function caller's paremeter choices to a small set of symbols, and as it is, the enum type-checking isn't strong enough to do that. I might as well be using char's as parameters and #defining constants for them.
fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000) (10/19/90)
chaffee@reed.UUCP (Alex Chaffee) writes: > - how about true inline functions? Come on; you've got an assembler and a > compiler right there; why make us hand-assemble our inline functions into > machine code? (cf. p.125) Something like >inline pascal void PrOpenPage() { > asm { > move.l #0x10000808, -(SP) > _PrGlue > } >} THINK C already allows you to define this is a macro, that would yield exactly the same code as the inline would. -- Frank Owen (fjo@mtcchi.uucp) 708-305-3182 Memorex-Telex Corporation Indian Hill Court 1000 E. Warrenville Rd. RM 1A315 Naperville, Il 60563
morse@currituck.cs.unc.edu (Bryan Morse) (10/21/90)
In article <1990Oct18.191531.29325@mtcchi.uucp> fjo@mtcchi.uucp (2667-Frank Owen(ZG90210)0000) writes: >THINK C already allows you to define this is a macro, that would yield >exactly the same code as the inline would. True, but sometimes macros just don't cut it. Inline functions give you prototypes, breakpoints, etc. that you just can't do with a macro. Besides, we *all* know the headaches of macros, don't we? One more vote for inline functions... Bryan Morse morse@cs.unc.edu
rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) (10/30/90)
I haven't been following this thread, so maybe this has been suggested
a million times already, but...
The 32k code segment limitation in Think C drives me nuts. It
is especially a problem when porting other packages (like NCSA's HDF
or Unidata netCDF), or if you have code that is growing. It is a
nuisance especially to have to break up a library into lots of
little bits.
Other compilers don't have this restriction. Can it be eliminated
in Think C without a big performance hit?