home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12588 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  4.0 KB
  1. Path: sparky!uunet!pipex!unipalm!uknet!mcsun!sunic!seunet!appli!niklas
  2. From: niklas@appli.se (Niklas Hallqvist)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Doubly-linked list trick (was Re: Garbage Collection for C++)
  5. Message-ID: <2137@appli.se>
  6. Date: 19 Aug 92 19:29:37 GMT
  7. References: <1992Aug14.021547.15215@news.mentorg.com>>     <DAVEG.92Aug14194411@synaptx.synaptics.com> <2009@appli.se>     <16ovt2INN3nq@early-bird.think.com> <2134@appli.se> <TMB.92Aug19133241@arolla.idiap.ch>
  8. Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN
  9. Lines: 73
  10.  
  11. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  12.  
  13. :In article <2134@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
  14.  
  15. :   Emphasises mine!  This means the trick WILL be portable to all platforms
  16. :   where there exists an integral type large enough (ie. almost all platforms).
  17. :   I agree that this may be a bad habit, BUT... what I wanted to tell was:
  18. :   It's REAL HARD (read: impossible) to implement GC on most architectures if
  19. :   this rule [allowing conversions of pointers to/from integers] is left in.
  20.  
  21. :No, it's not at all hard. Since C++ programs that rely on
  22. :integer/pointer conversions are already unportable, a very small
  23. :number of these already unportable programs would simply be unportable
  24. :to a larger number of implementations.
  25.  
  26. Excuse me, but I don't understand.  My interpretation of the ARM is that
  27. given your implementation supplies an integral type with more (or equal
  28. amount of) bits than a void pointer, you can safely cast any pointer to
  29. that integral type, fiddle with this integer in a reversible way, do the
  30. reverse transformation, cast it back and get the original pointer.  Thus,
  31. if you know your implementation meets this prerequisite, then running a
  32. program only unportable in this way WILL produce the same results on
  33. every such architecture since the ARM guarantees it.  Adding conservative
  34. GC might change this invariance.  So, I conclude the ARM must be rephrased
  35. in order to enable GC.
  36.  
  37. Actually, I find it strange that the ARM states a facility to be well-
  38. defined under certain conditions and implementation dependent otherwise
  39. instead of just saying it's implementation dependent.  I'm sure there
  40. are a rationale for this, if someone has, please tell me.
  41.  
  42. :In practice, none of this is a significant problem: even if you carry
  43. :out integer/pointer conversions, almost all of the time you are going
  44. :to keep the real pointer around, either as an integer or as a pointer.
  45. :Those old program programs that don't (if any) can be run either with
  46. :GC turned off, or they can be modified slightly to keep the original
  47. :pointers around.
  48.  
  49. No argument, but I wasn't talking of practice :-)
  50.  
  51. :C/C++ has undergone significantly greater changes than this.
  52.  
  53. :For a more extensive discussion of these issues, I suggest looking at
  54. :comp.compilers.
  55.  
  56. I will see to we will get this group here, we have had a limited news-
  57. feed here during the summer.  Too bad, I'd want to get that discussion :-(
  58.  
  59. :                    Thomas.
  60.  
  61. :PS: Where was the outcry of indignation when, all of a sudden,
  62. :uninitialized static member definitions didn't count as definitions
  63. :anymore? Unlike restricting encoded pointers, this did force me to
  64. :change some of _my_ source code.
  65.  
  66. In gnu.g++.bugs, there has been lots of outcries when G++ changed in this
  67. way.  Well, you asked :-)  I won't cry out, if we'll restrict encoded
  68. pointers.  What's important is that we DO restrict them if we bless GC.
  69.  
  70. :PPS: As to the XOR trick, you can use doubly linked lists of small
  71. :arrays of elements to get equivalent space savings portably.
  72.  
  73. Yes, but in order to keep these savings you have to move elements between
  74. arrays every time you add/remove elements in the middle of the list.
  75. Otherwise you may have half full arrays spending the saved space.
  76. Those element movements can be quite expensive... but you're right,
  77. it's definitely more portable, and used as stacks and queues, they should
  78. work real well.
  79. -- 
  80. Niklas Hallqvist    Phone: +46-(0)31-40 75 00
  81. Applitron Datasystem    Fax:   +46-(0)31-83 39 50
  82. Molndalsvagen 95    Email: niklas@appli.se
  83. S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
  84.