home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12804 < prev    next >
Encoding:
Text File  |  1992-07-21  |  4.1 KB  |  80 lines

  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!think.com!cass.ma02.bull.com!mips2!bubba!sje
  3. From: sje@xylos.ma30.bull.com (Steven J. Edwards)
  4. Subject: A few more suggestions for THINK C
  5. Reply-To: sje@xylos.ma30.bull.com
  6. Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
  7. Distribution: comp
  8. Date: 20 Jul 92 18:06:20
  9. Message-ID: <SJE.92Jul20180620@xylos.ma30.bull.com>
  10. Sender: news@mips2.ma30.bull.com (Usenet News Manager)
  11. Lines: 67
  12.  
  13. Here are a few little things I would like to see in future THINK C
  14. development.  For what it's worth:
  15.  
  16. 1) Filenames in the project window should use a monospace font,
  17. perhaps our beloved Monaco 9.  I think that tabular data should at
  18. least allow monospace fonts, and I think Apple also shares this view
  19. to some extent.  I note that they encourage monospace digits even in
  20. non-monospace fonts for this reason.
  21.  
  22. 2) The project window should have indicators for each entry that flag
  23. libraries versus plain source files.  A double click on a library
  24. entry should do something of interest, perhaps identifying some info
  25. about the library project.
  26.  
  27. 3) The transfer menu selection on the File menu does not do anything
  28. if the selected program cannot be run due to memory limitations.  I
  29. think that there should be two menu picks: one named "Exec" that works
  30. like a Unix exec call, and one named "Chain" (or "Transfer") that
  31. terminates THINK C and starts the indicated program.  This second call
  32. would be something new and usable by those with fat programs and slim
  33. memory.  (An example:  I have 4 MByte, but my application takes 3
  34. MByte and a THINK C Transfer won't work; but a chain would.)
  35.  
  36. 4) There should be some kind of autosegmentation option with the
  37. project window.  Why should a deveoper fiddle with moving project
  38. entries around?  It would be much nicer if THINK C could just generate
  39. code segment partitioning without human intervention.  How hard is it
  40. to count to 32 KByte?  After all, the compiler already keeps track of
  41. this information.
  42.  
  43. 5) There should be some kind of hook in THINK C project scanning that
  44. allows a developer to specify some third party program to be
  45. automatically invoked on C sources at specified times.  For example, a
  46. third party semantic checker could be called each time after source
  47. file is compiled correctly.  An indentation or pretty printer source
  48. processor could be called after a file is changed and successfully
  49. compiled but before it is printed.  I think that this kind of option
  50. would go a long way in keeping down the demand for functions secondary
  51. to compilation in THINK C itself.  If this is done cleverly enough,
  52. THINK C could be re-invoked by some small lurker program so the whole
  53. scheme would work on small systems.
  54.  
  55. 6) The project file should keep track of potential conflicts in
  56. compilation option values among user files and libraries.  Thus, an
  57. unwary user would be warned if he/she chose incompatable type size
  58. selections between a user program and a supplied library.
  59.  
  60. 7) There is a lot to do with C, but it is unclear that it is wise for
  61. one product to do it all.  I am wary of the direction of C programming
  62. for the DOS/Windows world where some suppliers want to be all things
  63. to all developers in a single package.  A better approach is to
  64. segregate along commonsense boundaries so developers can get and pay
  65. for what they need; no more and no less.  I would prefer that THINK C
  66. have a single core product that included the integrated editor,
  67. compiler, and linker.  The class library could be a separate part, as
  68. could be the C++ effort.  I've personally dealt with the
  69. multi-kilogram unitary C development packages from Borland, Microsoft,
  70. and SCO; I really don't need another one from Symantec.  I can see the
  71. bumpersticker now:
  72.  
  73.     "Save a tree and buy THINK C"
  74.  
  75.  [The above opinions expressed are my own; not necessarily held by others.]
  76.       == Steven J. Edwards           Bull HN Information Systems Inc. ==
  77.       == (508) 294-3484              300 Concord Road         MS 820A ==
  78.       == sje@xylos.ma30.bull.com     Billerica, MA 01821          USA ==
  79. "That Government which Governs the Least, Governs Best." -- Thomas Jefferson
  80.