Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!stanford.edu!agate!web-4e.berkeley.edu!c60b-1eq From: c60b-1eq@web-4e.berkeley.edu (Noam Mendelson) Newsgroups: comp.lang.c Subject: Re: Little problem with sizeof on PC Message-ID: <1991Apr24.212513.25621@agate.berkeley.edu> Date: 24 Apr 91 21:25:13 GMT References: <1991Apr24.031700.17233@agate.berkeley.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 31 In article enag@ifi.uio.no (Erik Naggum) writes: >In article <1991Apr24.031700.17233@agate.berkeley.edu>, Noam Mendelson writes: > > If you want to take up disk space unnecessarily and decrease > program performance, sure, you can create ASCII data files. > Portability will be limited to the Intel 80x86 line, however, if > you opt to use the binary method. > >If you want to take up debugging time unnecessarily and decrease >programmer performance, sure, you can create binary data files. Decrease programmer performance? Read()'ing in the data structure causes a lot less headache than trying to fscanf() in the data from an ASCII data file. >Portability and debug-ability will be be unlimited, however, if you ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >opt to use the readable data file method. So I assume you've never had any problems doing I/O on ASCII files. ASCII data files produce a whole new set of problems that don't exist with the binary format, ranging from the fscanf() syntax to the record size. Portability will be dramatically increased, although not unlimited. -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |