home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / os2 / programm / 7941 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.8 KB  |  68 lines
  1. Newsgroups: comp.os.os2.programmer
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!ljensen
  3. From: ljensen@netcom.com (Colin Jensen)
  4. Subject: Re: emx/gcc very forgiving!!
  5. Message-ID: <1993Jan23.192018.21475@netcom.com>
  6. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  7. References: <1993Jan20.045839.25052@netcom.com> <1993Jan20.102705.23327@jarvis.csri.toronto.edu> <1jkjleINNfn9@gap.caltech.edu>
  8. Date: Sat, 23 Jan 1993 19:20:18 GMT
  9. Lines: 57
  10.  
  11. In article <1jkjleINNfn9@gap.caltech.edu> brooke@cco.caltech.edu (Brooke Paul Anderson) writes:
  12. >byu@sys.toronto.edu (Benjamin Yu) writes:
  13. >
  14. >>In article <1993Jan20.045839.25052@netcom.com> ljensen@netcom.com (Colin Jensen) writes:
  15. >>>I use a hybrid gcc/2 gcc-2.3.3 compiler, and it says:
  16. >>>forgive.cc:6: warning: assignment of non-`const *' pointer from `const *'
  17. >>>
  18. >
  19. >>emx/gcc does indeed give a warning, but I was hoping it wouldn't even allow it ..
  20. >>hence I call it "forgiving"!
  21.  
  22. Benjamin is right.  The C++ Annotated Reference Manual (ARM) indicates that
  23. this must be considered an error.  Gcc issues a warning - but the ARM says
  24. that this is not good enough.  Personally, I think the ARM is being overly
  25. pedantic.
  26.  
  27. >>>>It allows me to have amibiguous overloaded functions.  
  28. >>>Not sure what you mean.  How about a sample?
  29. >>>
  30. >>  elevator() { floor_selected = 0; floor_number = 0;} ;
  31. >>  elevator(int x = 10, int y = 10) { floor_selected = x; floor_number = y; };
  32. >
  33. >If it gives you a warning, I'd say that's good enough.  Also, your
  34. >overloaded function doesn't look ambiguous at all to me.  One takes two
  35. >ints as arguments; the other takes no arguments.
  36.  
  37. The code
  38.     elevator(int x=10, int y=10)
  39. indicates that it is legal to call the second elevator function with
  40. zero arguments (and that x will be 10, and y will be 10 in the called
  41. elevator() function).
  42.  
  43. Clearly, the first elevator function is also intended to be called with no
  44. arguments.
  45.  
  46. Therefore, is you write some code like
  47.     if (foo) elevator();
  48. either version of the overloaded function elevator "matches" this
  49. call pattern - in other words elevator() is ambiguous.
  50.  
  51. The ARM states that the declaration of the two ambiguous elevator
  52. functions should generate an error.  Gcc does not.  In this case gcc
  53. fails to even warn about the problem - even if you *use* the elevator()
  54. function.
  55.  
  56. The real problem is that the C++ language is so @#$%^& complex that
  57. it is a very difficult language to parse correctly for legal programs.
  58. Parsing the wrong programs and noticing what is wrong is even harder.
  59.  
  60. For example, the excellent Borland C++ 3.0 compiler sometimes fails to catch
  61. errors until several lines after the mistake - and it issues an unrelated
  62. error message to boot.  And the behavior of the Cfront compiler is
  63. sometimes just bizarre.  So it goes.
  64.  
  65. -- 
  66. Colin Jensen
  67. ljensen@netcom.netcom.com    cjensen@ampex.com
  68.