home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18244 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  1.8 KB
  1. Path: sparky!uunet!ontek!mikey
  2. From: mikey@ontek.com (euphausia superba)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Locating A Record Within A File
  5. Message-ID: <2197@ontek.com>
  6. Date: 11 Dec 92 19:42:33 GMT
  7. References: <1992Nov24.174656.25265@nosc.mil> <1992Dec03.100851.5809@cadlab.sublink.org>
  8. Organization: Ontek Corporation -- Laguna Hills, California
  9. Lines: 30
  10.  
  11. In comp.lang.c, martelli@cadlab.sublink.org (Alex Martelli) writes:
  12. | mitch@nosc.mil (Ray Mitchell) writes:
  13. | 
  14. | :Assume that a file consists of a series of records and it is desired to
  15. | :locate a specific record.  My assumption is that in the general case it
  16. | :is not portable to simply fseek or fsetpos to (sizeof(record) * recordnumber)
  17. | :since a file can contain more than just the individual bytes forming each
  18. | :record.  Instead, the file should start with a table of offsets, initially
  19. | :determined by ftell or fgetpos, which may be later given back to fseek or
  20. | :fsetpos to locate the desired record.
  21. | 
  22. | [discussion of solutions to problem of growing the size of the
  23. |  lookup table]
  24.  
  25. I sense a fallacy here.  Since the lookup table itself is part
  26. of the file, you can't index into it any more portably than you
  27. could have indexed into the records themselves.  The overhead of 
  28. reading is that of sequentially reading the table of record
  29. offsets until finding the offset for the record you're interested
  30. in.  This will be faster if the size of the entries in the index
  31. is significantly smaller than the size of the records, but it will
  32. be a far cry from fseek.
  33.  
  34. Possible ways of achieving the random-access behavior you describe
  35. are (a) carrying around an fpos_t wherever you would have previously
  36. wanted to have "record number" or (b) constructing a lookup table
  37. in memory ahead of time.
  38.  
  39.        the krill, i guess off_t is out of the question
  40.  
  41.