home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12982 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  2.0 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!forney.berkeley.edu!jbuck
  2. From: jbuck@forney.berkeley.edu (Joe Buck)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: risky inline
  5. Date: 27 Aug 1992 18:54:42 GMT
  6. Organization: U. C. Berkeley
  7. Lines: 39
  8. Message-ID: <17j8diINNo0p@agate.berkeley.edu>
  9. References: <1992Aug27.142700@uni-paderborn.de>
  10. NNTP-Posting-Host: forney.berkeley.edu
  11. Keywords: inline, safe programming
  12.  
  13. In article <1992Aug27.142700@uni-paderborn.de> trachos@uni-paderborn.de (Konstantin Trachos) writes:
  14. >Inline-expansion is surely more effective than #defines, but it isn't
  15. >less risky than that.
  16.  
  17. Inline expansion is FAR less risky than macros, because type-checking is
  18. done and because the parsing is the same as if it were a regular function.
  19. However, inline functions have file scope only (I would say they are
  20. static, but unfortunately Stroustrup gave that word one too many
  21. meanings).  For this reason you must never do what your example does,
  22. which I abbreviate:
  23.  
  24. >// Interface C.hxx -----------------------------
  25. >   class C{
  26. >          int c();
  27. >   };
  28. >
  29. >// Code C.cxx ----------------------------------
  30. >   #include "C.hxx"
  31. >   inline int C::c() {return 1;}// !
  32.  
  33. You've basically put a lie in your C.hxx file: you've told users of
  34. that file that someone will supply a global C::c(), but C.cxx supplies
  35. only a local C::c().
  36.  
  37. The solution is that if you put a declaration of a function in a header
  38. file, you must supply a global definition somewhere (it can't be inline).
  39. If you want an inline function, it must be in the header file. With some
  40. compilers there are ways around this, but if your code is to run under
  41. several compilers, you need to follow this rule.
  42.  
  43. But to claim on the basis of this one little gotcha that inline functions
  44. are not any less risky than macros is to lose all sense of proportion.
  45. It's evident that you didn't understand the rule about the local scope
  46. about inline functions.
  47.  
  48.  
  49.  
  50. --
  51. Joe Buck    jbuck@ohm.berkeley.edu
  52.