home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18721 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.2 KB  |  53 lines
  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Subject: Re: Small objs & When/whether to overload "new" with statics
  5. Reply-To: nikki@trmphrst.demon.co.uk
  6. References: <1993Jan04.162941.13841@rchland.ibm.com>
  7. Distribution: world
  8. X-Mailer: cppnews $Revision: 1.30 $
  9. Organization: Trumphurst Ltd.
  10. Lines: 38
  11. Date: Tue, 5 Jan 1993 18:34:19 +0000
  12. Message-ID: <726284059snx@trmphrst.demon.co.uk>
  13. Sender: usenet@demon.co.uk
  14.  
  15. In article <1993Jan04.162941.13841@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
  16. [ BitRef class def omitted]
  17.  
  18. > Now, I am less interested in the particular virtues and vices of 
  19. > BitRef per se than in what to do _in general_ with helper objects of
  20. > that kind.  Note carefully that in the normal course of events, BitRef
  21. > will never be formally declared.  It will arise, normally, as a temporary
  22. > in various objects' operator[].  There are many such potential objects.
  23. > 
  24. > Optimizing such objects can be important, especially if they "help" 
  25. > functions like operator[], because they may appear in inner "for" loops.
  26.  
  27. One obvious optimisation would be to adjust data to point to the actual 
  28. byte containing the bit you want, so that loc is always between 0 and 7.
  29.  
  30. > I especially wonder about "new" and "delete".
  31. > 
  32. > For machines with enough registers, one presumes that the above code 
  33. > could work out fairly nicely, as is.  Each data element of an instance 
  34. > of BitRef could imaginably have both of its small pieces optimized into 
  35. > a register, especially since the compiler, since it creates it, is in 
  36. > full control of how long the instances live.
  37. > 
  38. > For a PC-type machine, however, such optimization seems unlikely (is
  39. > that so?).  
  40.  
  41. It is so on all the compilers I have used. I don't think I have ever seen 
  42. a PC compiler optimise a structure into registers.
  43.  
  44. > Therefore, _if_ the compiler's generation of "temps" uses
  45. > new and delete, one would be tempted to add something like the following
  46. > to BitRef
  47.  
  48. Ah, but they don't (as a rule), they allocate space on the stack.
  49.  
  50. -- 
  51. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  52. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  53.