home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18265 next >
Encoding:
Text File  |  1992-12-21  |  3.4 KB  |  80 lines
  1. Xref: sparky comp.lang.c++:18265 comp.std.c++:1871
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!ut-emx!jamshid
  3. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: inlining friend functions
  6. Summary: 'inline friend' legal (and required), BC++ bug
  7. Message-ID: <85645@ut-emx.uucp>
  8. Date: 21 Dec 92 07:35:58 GMT
  9. References: <1992Dec15.182858.22555@aruba.uucp> <1992Dec16.130156.1@vax1.bham.ac.uk>
  10. Reply-To: jamshid@emx.utexas.edu
  11. Followup-To: comp.lang.c++
  12. Organization: The University of Texas at Austin; Austin, Texas
  13. Lines: 65
  14.  
  15. I'm crossposting to comp.std.c++ since I asked this a few months ago but
  16. it was never publicly answered there.
  17.  
  18. In article <1992Dec16.130156.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
  19. >In article <1992Dec15.182858.22555@aruba.uucp>, sandys@aruba.UUCP (Sandy Schindler) writes:
  20. >>   Error inl.hh, line xx: Storage class 'inline' is not allowed here 
  21. >> Borland will not allow the inline keyword to used on a friend function 
  22. >> inside a class declaration, no matter where the definition happens.
  23. >
  24. >I never put inline in the class definition when declaring friends. Simply
  25. >putting inline in the function definition is sufficient.
  26.  
  27. Actually, I think 'inline' is *required* in the class declaration if
  28. the function will later be defined inline (and you haven't previously
  29. declared it inline).
  30.  
  31.     class X {
  32.        friend void f();// no 'inline', considered 'extern' (11.4)
  33.     };
  34.     inline void f() {} // error: defining 'extern' func inline (7.1.1)
  35.  
  36. r11.4 says "A function first declared in a friend declaration is
  37. equivalent to an extern declaration".  r7.1.1 says "For a nonmember
  38. function an inline specifier is equivalent to a static specifier for
  39. linkage purposes.  All linkage specifications for a name must agree.
  40. For example,
  41.     [...]
  42.     char* g();    // g() has external linkage
  43.     static char* g() {/*...*/}    // error: inconsistent linkage
  44. ".
  45.  
  46. >As far as I know
  47. >Borland is right and the inline storage class should only appear in a
  48. >function definition and not in a friend declaration that is not also acting
  49. >as the definition.
  50.  
  51. The grammar allows it:
  52.     member-list: member-declaration ...
  53.     member-declaration: decl-specifiers...
  54.     decl-specifiers: decl-specifiers(opt) decl-specifier
  55.     decl-specifier: friend | fct-specifier
  56.     fct-specifier: inline | virtual
  57.  
  58. And as I showed above, the language seems to require it.  I'm not sure
  59. if any compiler would actually give an error if you declare a friend
  60. without 'inline' and later define the function inline.  I imagine most
  61. are lax and treat friend functions like member functions: you can
  62. define it inline, even if it was not declared 'inline', at any point
  63. before it's first called.
  64.  
  65. >> Is this a mere compiler bug on Borland's part, or is this the first 
  66. >> appearance of a standard restriction?
  67.  
  68. It's a Borland bug that I reported a few months ago when I was porting
  69. the GE COOL library to BC++ 3.1 using real templates.  I littered the
  70. code with '##'-marked comments like:
  71.     /*inline##*/ friend ostream& operator<<(ostream&,const X<T>&);
  72. to indicate a BC++ bug work-around.  The library is available at
  73. cs.utexas.edu in pub/COOL/JCOOL.ZIP; see JCOOL.TXT for more
  74. information.  I highly recommend trying to compile JCOOL if you
  75. use or are beta-testing a compiler supporting templates -- it will
  76. probably find lots of bugs that you can report.
  77.  
  78. Jamshid Afshar
  79. jamshid@emx.utexas.edu
  80.