home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18291 < prev    next >
Encoding:
Internet Message Format  |  1992-12-13  |  2.0 KB
  1. Xref: sparky comp.lang.c:18291 comp.std.c:3196
  2. Path: sparky!uunet!mcsun!Germany.EU.net!mikros!mwtech!martin
  3. From: martin@mwtech.UUCP (Martin Weitzel)
  4. Newsgroups: comp.lang.c,comp.std.c
  5. Subject: Re:  Is this ANSI: final (long)
  6. Message-ID: <1363@mwtech.UUCP>
  7. Date: 13 Dec 92 12:01:33 GMT
  8. References: <Zc15uB4w165w@quest.UUCP> <723773123.1323@hitech.com.au> <alien.01ss@acheron.amigans.gen.nz> <Bz3n1I.73o@unx.sas.com>
  9. Reply-To: martin@mwtech.UUCP (Martin Weitzel)
  10. Organization: MIKROS Systemware, Darmstadt/W-Germany
  11. Lines: 36
  12.  
  13. In article <Bz3n1I.73o@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
  14. :
  15. :In article <alien.01ss@acheron.amigans.gen.nz>, alien@acheron.amigans.gen.nz (Ross Smith) writes:
  16. :
  17. :|> 
  18. :|> I've seen this idiom before, but I've never seen the point of it. Why not just
  19. :|> use a pointer instead of kludging it up with a fake array?
  20. :|> 
  21. :|>    struct FM
  22. :|>       {
  23. :|>       int data_count;
  24. :|>       char *data;     /* Again, might be int for alignment */
  25. :|>       }
  26. :|>       thing;
  27. :|> 
  28. :|>    ...
  29. :|> 
  30. :|>    thing.data = malloc(extra_data_size);
  31. :|>    thing.data_count = extra_data_size;
  32. :
  33. :The point is this:  If you are dynamically allocating *both* the
  34. :structure and the data, the approach you suggest requires *two*
  35. :separate allocations (and two separate frees if you will be freeing
  36. :the stuff).  The goal is to reduce the calls to the memory management
  37. :functions.  Doing so can result in easily measureable performance
  38. :improvements.  Likewise, you have the extra overhead of setting
  39. :the pointer to the new memory, but this isn't much.  So to reduce
  40. :the call overhead you *could* allocate a big chunk and use the first
  41. :part of it for the structure and the rest for the data.
  42.  
  43. Yes, and there's another point:  With a single allocation you may
  44. memcpy/memmove/memcmp/[f]read/[f]write the whole easily.  Each of
  45. this would become a specialized operation if you separate the size
  46. from the data.
  47. -- 
  48. Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
  49.