home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19653 < prev    next >
Encoding:
Text File  |  1993-01-21  |  1.8 KB  |  65 lines
  1. Xref: sparky comp.lang.c++:19653 gnu.g++.help:1684
  2. Newsgroups: comp.lang.c++,gnu.g++.help
  3. Path: sparky!uunet!spool.mu.edu!enterpoop.mit.edu!bloom-picayune.mit.edu!fritz
  4. From: fritz@mtl.mit.edu (Frederick Herrmann)
  5. Subject: References to functions?
  6. Message-ID: <1993Jan21.044013.1429@athena.mit.edu>
  7. Followup-To: comp.lang.c++
  8. Sender: news@athena.mit.edu (News system)
  9. Nntp-Posting-Host: wayne.mit.edu
  10. Organization: MIT Microsystems Technology Laboratories
  11. Date: Thu, 21 Jan 1993 04:40:13 GMT
  12. Lines: 51
  13.  
  14. I tried to declare a reference to a function, but found that g++
  15. wouldn't let me.  After scanning ch. 8 of the ARM, I interpret it to
  16. forbid function references, but it's not all that clear (see below).
  17.  
  18. Here's what I was trying to do:
  19.  
  20.     typedef void (&rfi)(int);
  21.     typedef void (*pfi)(int);
  22.  
  23.     class X {
  24.     public:
  25.       rfi f;
  26.  
  27.       X( pfi ff) : f( *ff) {};
  28.  
  29.       void some_member_func( int i) { f(i); }
  30.     };
  31.  
  32. Looks reasonable to me, except I can hear the grumbling that f is not
  33. properly initialized, since ff could be a dangling pointer.  On the
  34. other hand, g++ lets me get away with this:
  35.  
  36.     class Y {
  37.     public:
  38.       int& ri;
  39.  
  40.       Y( int* pi) : ri( *pi) {};
  41.     };
  42.  
  43. which has the same problem when I construct Y(0).
  44.  
  45. Now ARM 8.4.3 says a reference must be initialized by an "object", and
  46. if a function is not an object then class X is out.  But the last
  47. paragraph of 8.2.2 gives a long list of things that can't be
  48. referenced, and functions are not listed.
  49.  
  50. It's not a big deal to me, since it's really a matter of notational
  51. convenience.  I'd be grateful for some discussion; can someone tell me:
  52.  
  53. * A place in the ARM or other source where this is more clearly
  54.   forbidden.
  55.  
  56. * An explanation of implementation issues or other reasons why
  57.   function references are a bad idea.
  58.  
  59. * Whether other compilers can handle class Y above; is this a g++ bug?
  60.  
  61.             Thanks,
  62.  
  63.                 - Fritz
  64.                   fritz@mtl.mit.edu
  65.