Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!gatech!mcnc!ece-csc!jnh From: jnh@ece-csc.UUCP (Joseph Nathan Hall) Newsgroups: comp.sys.mac.programmer Subject: Re: Line-oriented File IO Message-ID: <4019@ece-csc.UUCP> Date: 14 Apr 89 16:43:16 GMT References: <451@biar.UUCP> <28839@apple.Apple.COM> <4012@ece-csc.UUCP> <6987@hoptoad.uucp> <4015@ece-csc.UUCP> <13054@dartvax.Dartmouth.EDU> Reply-To: jnh@ece-csc.UUCP (Joseph Nathan Hall) Organization: North Carolina State University, Raleigh, NC Lines: 31 In article <13054@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >In article <4015@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >> ...In systems that provide fast character I/O, it can >> be SLOWER to do the "raw" block reads yourself if you have to >> write the supporting code in a HLL. > I have to agree with Tim on this one. Microemacs, which I ported >to the Mac, uses newline mode to read in text files. In fact, the ... [microemacs is slower than another RAM-based editor which uses block reads] I won't argue this point in the case of the Macintosh; however, your results will vary depending upon operating system and language support. It's mere coincidence, also, if your internal text format happens to match up with your disk file format. The ubiquitous TextEdit example where the code to load and save a text file is about 10 lines long per function is elegant for precisely this reason. I presume, also, that Microemacs and several other text-only editors use this format for convenience. The advantage of using the O/S-supplied newline mode (to me) is that it is more versatile than the corresponding "C" and Pascal equivalents without being that much more complex. It's reasonably fast and easier to prototype with. Then again, your personal preferences may vary. -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || joseph@ece007.ncsu.edu (Try this one first) -----------|| Standard disclaimers and all that . . . . . . . . . . . . . .