home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12694 < prev    next >
Encoding:
Text File  |  1992-08-20  |  1.3 KB  |  29 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug20.212200.16033@microsoft.com>
  6. Date: 20 Aug 92 21:22:00 GMT
  7. Organization: Microsoft Corporation
  8. References: <2009@appli.se> <TMB.92Aug17204854@arolla.idiap.ch> <1992Aug18.045533.7193@actrix.gen.nz>
  9. Lines: 18
  10.  
  11. In article <1992Aug18.045533.7193@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes:
  12. |In article <TMB.92Aug17204854@arolla.idiap.ch> tmb@idiap.ch writes:
  13. |> 
  14. |> Incidentally, there is a widely used, simple, efficient, more general,
  15. |> and completely portable technique for getting the same kinds of
  16. |> storage savings as with the XOR trick.
  17. |
  18. |Well you can trivially subtract the pointers instead of XORing them.
  19. |That would be more portable in practise, although I don't think ANSI C
  20. |guarentees that you can subtract arbitrary pointers. but only ones to
  21. |elements of the same array or struct.
  22.  
  23. There are Order(100,000,000) computers in the world where subtracting pointers
  24. not to the same array will not produce the results you desire.  -- Not to imply
  25. XORing pointers is a good idea either!   If you want to write portable
  26. code, start by making no assumptions equating pointers to ints.  Historically,
  27. any code that hacks pointer bits sooner or later proves to be a stumbling
  28. block.
  29.