home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13676 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.0 KB  |  60 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: inline virtual functions
  5. Message-ID: <9226000.11363@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Sep15.023336.1403@cs.brown.edu>
  9. Date: Tue, 15 Sep 1992 14:31:30 GMT
  10. Lines: 48
  11.  
  12. sdm@cs.brown.edu (Scott Meyers) writes:
  13.  
  14. >For all the compilers with which I am familiar, inline virtual functions
  15. >are oxymoronic:  the function bodies are never inlined, and the object file
  16. >for each translation unit seeing the definition of the function receives a
  17. >static copy of the function.  I tested this using cfront 3.0 and g++ 2.2.2,
  18. >and both behaved as I have described, neither issuing a warning about not
  19. >inlining a function.
  20.  
  21. I just tested cfront 1.2.1, cfront 2.0, g++ 1.37.2, and g++ 2.2.2.
  22. All of these except cfront 1.2.1 can successfully inline "inline virtual"
  23. functions. Perhaps you made some mistake?
  24.  
  25. Here's the code I used:
  26.  
  27.     extern void ggggg();    // "ggggg" easy to find in the assembly output
  28.  
  29.     class A {
  30.     public:
  31.         inline virtual void fffff() { ggggg(); }
  32.     };
  33.  
  34.     void foo() {
  35.         A a;
  36.         A& b = a;
  37.         a.fffff();    // this gets inlined
  38.         b.fffff();    // this doesn't :-(
  39.     }
  40.  
  41. >Many people have discovered this behavior in current compilers, and so the
  42. >following rule is widely followed: "never define an inline virtual
  43. >function."
  44.  
  45. Not by me!
  46. That would not be a good rule to follow.
  47.  
  48. >This is a pity, because it's the kind of rule that is easy to
  49. >remember, hence people will continue to follow it even when C++ compilers
  50. >become agressive enough in their optimization to be able to generate
  51. >inlined calls to virtual functions.
  52.  
  53. Compilers are already that aggressive.
  54.  
  55. -- 
  56. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  57. This .signature virus is a self-referential statement that is true - but 
  58. you will only be able to consistently believe it if you copy it to your own
  59. .signature file!
  60.