home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11712 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  1.5 KB

  1. Path: sparky!uunet!mcsun!sunic!news.funet.fi!hydra!klaava!wirzeniu
  2. From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Variable length records
  5. Message-ID: <1992Jul29.160618.27224@klaava.Helsinki.FI>
  6. Date: 29 Jul 92 16:06:18 GMT
  7. References: <24137@castle.ed.ac.uk> <rbjmzg-.gurgle@netcom.com> <1992Jul25.091702.15993@klaava.Helsinki.FI>
  8. Organization: University of Helsinki
  9. Lines: 22
  10.  
  11. In an earlier article I asked for what the advantages of using the
  12. non-standard "struct { ...; float data[];}" or the tricky but more
  13. standard "struct {...; float data[1];}" for structures where the data
  14. array may be of varying lengths.  I offered the "struct {...; float *}"
  15. version instead, as it is strictly conforming and will work everywhere.
  16.  
  17. The reasons for the trickery versions were convenience (no need for
  18. managing a separately allocated array), less wasted space (no additional
  19. pointer), and no need for a pointer dereference.  Your mileage may vary,
  20. but I don't think these are very good reasons, at least under normal
  21. circumstances.  If speed or size is critical, one's values may be
  22. different.
  23.  
  24. One point which I didn't think of until now (and which doesn't seem to
  25. have been pointed out by others) is that the '[]' and '[1]' versions
  26. don't allow using the structures as values, like for assignment,
  27. parameter passing and returning as function values.  This may or may not
  28. be important, but it is something you have to check for, as it could
  29. lead to difficult bugs, as such usage doesn't look wrong in itself.
  30.  
  31. --
  32. Lars.Wirzenius@helsinki.fi
  33.