home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18677 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.3 KB
  1. Xref: sparky comp.lang.c:18677 comp.std.c:3239
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!psuvax1!rutgers!mcdhup!src4src!wozzle!alane
  3. From: alane@wozzle.linet.org (J. Alan Eldridge)
  4. Newsgroups: comp.lang.c,comp.std.c
  5. Subject: Re:  Is this ANSI: final (long)
  6. Message-ID: <gggZVB1w165w@wozzle.linet.org>
  7. Date: 18 Dec 92 14:51:27 GMT
  8. References: <1363@mwtech.UUCP>
  9. Organization: Disorganization
  10. Lines: 20
  11.  
  12. martin@mwtech.UUCP (Martin Weitzel) writes:
  13.  
  14. > :The point is this:  If you are dynamically allocating *both* the
  15. > :structure and the data, the approach you suggest requires *two*
  16.  
  17. > Yes, and there's another point:  With a single allocation you may
  18. > memcpy/memmove/memcmp/[f]read/[f]write the whole easily.  Each of
  19. > this would become a specialized operation if you separate the size
  20. > from the data.
  21.  
  22. This is illegal in C++ for a good reason, and I find it inadvisable
  23. in C for similar reasons. For one, structure assignment is broken. For
  24. two, you are cheating what type safety there is in C. Neither one of
  25. these results is attractive in my opinion. I vote quite vehemently for
  26. allocating a separate data area and accessing it through an extra level 
  27. of indirection... if your CPU has problems because of the extra one or
  28. two instructions that are introduced, buy a real computer.
  29.  
  30. alane@wozzle.linet.org (J. Alan Eldridge)
  31. Fido: The University of Walamaloo 1:272/38.473
  32.