home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13686 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.8 KB  |  72 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!mike
  3. From: mike@taumet.com (Mike Ball)
  4. Subject: Re: inline virtual functions
  5. Message-ID: <1992Sep15.152147.12121@taumet.com>
  6. Organization: TauMetric Corporation, San Diego
  7. References: <1992Sep15.023336.1403@cs.brown.edu>
  8. Date: Tue, 15 Sep 1992 15:21:47 GMT
  9. Lines: 61
  10.  
  11. In article <1992Sep15.023336.1403@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
  12. >For all the compilers with which I am familiar, inline virtual functions
  13. >are oxymoronic:  the function bodies are never inlined, and the object file
  14. >for each translation unit seeing the definition of the function receives a
  15. >static copy of the function.  I tested this using cfront 3.0 and g++ 2.2.2,
  16. >and both behaved as I have described, neither issuing a warning about not
  17. >inlining a function.
  18.  
  19. In the case of both cfront and our own compiler inline virtual functions
  20. will be generated inline when the compiler can determine the exact function
  21. to execute.  This can be quite hard to determine for a virtual function, but
  22. you can test this on your own compiler by writing A::f() instead of f().
  23. Different compilers go to different amounts of trouble to make this
  24. optimization.
  25.  
  26. In the example below,
  27.  
  28. struct s {
  29.   virtual int f();
  30.   inline virtual int g() {return 1;}
  31.   s(){}
  32. };
  33.  
  34. extern s* sp;
  35. extern int i, j;
  36.  
  37. void foo() {
  38.     s sv;
  39.     i = sv.g();
  40.     j = sp->g();
  41. }
  42.  
  43. Our own compiler generates a non-virtual call to initialize i and a virtual
  44. call to initialize j.  I was surprised to discover that cfront 3.0 generates
  45. virtual calls in both cases.
  46.  
  47. >Many people have discovered this behavior in current compilers, and so the
  48. >following rule is widely followed: "never define an inline virtual
  49. >function."  This is a pity, because it's the kind of rule that is easy to
  50. >remember, hence people will continue to follow it even when C++ compilers
  51. >become agressive enough in their optimization to be able to generate
  52. >inlined calls to virtual functions.
  53.  
  54. Inlined polymorphic calls to virtual functions are unlikely unless the
  55. compiler is applying specialization techniques or has global knowledge of
  56. the program.  In fact, though, declaring them inline does no harm unless tools
  57. like the debugger can't handle inline functions.
  58.  
  59. >I was involved in a discussion of this issue today when it was suggested
  60. >that compilers should generate only a single copy of an out-of-line virtual
  61. >function, and that the single translation unit in which the function
  62. >definition should be generated should be the same as the one containing the
  63. >class's vtbl.  This seems sensible to me, so I was wondering: is there some
  64. >reason why compiler implementers don't do this?
  65.  
  66. No.  In general, that's what will happen.  Both cfront and our own compiler
  67. do exactly that in the case above.
  68.  
  69. -- 
  70. Michael S. Ball (mike@taumet.com)
  71. TauMetric Corporation
  72.