home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21118 < prev    next >
Encoding:
Text File  |  1993-01-10  |  1.5 KB  |  26 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!think.com!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!alexia!cole
  3. From: cole@alexia.lis.uiuc.edu (Sandra Stewart-Cole)
  4. Subject: Re: Why Control Segmentation?
  5. References: <1993Jan09.090047.8491@cosoco.com>
  6. Message-ID: <C0Mo2n.BDE@news.cso.uiuc.edu>
  7. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  8. Organization: University of Illinois at Urbana
  9. Date: Sun, 10 Jan 1993 07:42:22 GMT
  10. Lines: 14
  11.  
  12. The more control the better, but there are powers one should never need. There 
  13. is a clear advantage to having well thought out  and implemented segment 
  14. planning. Aside from the memory concerns of needing to keep multiple segments 
  15. around, there is always the simple performance penalties of far calls and the 
  16. jump table. I think the level of control is really a matter of working style. 
  17. With the by-file control of Think C, I get fine results, but I also have a lot 
  18. of different files. Provided the programmer designs the code well, there ought 
  19. to be no excuse for having an object splittable between segments (i.e. at the 
  20. function level) If I could split easily by object instead of file, I would 
  21. have an easier management problem in Think C. I doubt I would ever use an easy 
  22. ability to split my objects by function, but if I did a lot more procedural 
  23. work, it might be nice (i.e. maybe encourage good object design) to NOT allow 
  24. segmentation by function inside objects, but allow it for procedural code 
  25. (maybe by thinking of procedures as tiny objects...) 
  26.