Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!well!gurgle@well.sf.ca.us From: gurgle@well.sf.ca.us (Pete Gontier) Newsgroups: comp.sys.mac.programmer Subject: Yet more THINK C suggestions Message-ID: <21107@well.sf.ca.us> Date: 9 Oct 90 23:32:05 GMT Sender: gurgle@well.sf.ca.us Organization: cellular Lines: 47 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 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.