home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / cplus / 2111 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.7 KB

  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!Germany.EU.net!mikros!mwtech!martin
  2. From: martin@mwtech.UUCP (Martin Weitzel)
  3. Newsgroups: comp.std.c++
  4. Subject: "const" in arglist part of function type?
  5. Message-ID: <1387@mwtech.UUCP>
  6. Date: 24 Jan 93 17:42:57 GMT
  7. Reply-To: martin@mwtech.UUCP (Martin Weitzel)
  8. Organization: MIKROS Systemware, Darmstadt/W-Germany
  9. Lines: 54
  10.  
  11. (Note to Readers of `comp.lang.c' and `comp.lang.c++': This is a modified
  12. repost of a question I recently posted to the above groups.  Since the
  13. answers I received were not quite satisfactory regarding the C++ aspects,
  14. I post it again here.)
  15.  
  16. Background: For certain reasons I'm trying to write programs in a way
  17. so that they can be compiled with either an ANSI-C- or a C++-compiler.
  18.  
  19. Problem:  The following is the narrowed down failing case where my
  20. C++-compiler (Comeau 3.0 on ISC UNIX) rejected some piece of code that
  21. is valid ANSI-C (according to my SysV.R4 compiler and to Jutta Degener
  22. who pointed out in private mail that the `const'-ness of a function's
  23. argument is not part of the function's type in ANSI-C).
  24.  
  25.     void foo(const int i) { /* i not modified here */ }
  26.     ...
  27.     void (*bar)(int) = foo;
  28.  
  29. Question 1:  Has the C++ standardization already an opinion on this,
  30. i.e. is this is an *intentional* deviation from ANSI-C?
  31.  
  32. Corretions: I see the following ways to make the program acceptable for
  33. both, ANSI-C and C++.
  34.  
  35.     a) add `const' to bar's parameter declaration;
  36.     b) delete `const' from foo's parameter declaration;
  37.     c) use an explicit `(void (*)(int))'-cast in the assignment.
  38.  
  39. Option a) is of no value, since in the `real' program I need to assign
  40. different functions to bar, some of which need non-const parameters,
  41. hence it would just reverse the problem.
  42.  
  43. Option b) is the way I use right now(*1), but it is somewhat unsatisfactory
  44. that I'm not able to protect foo's argument against inadvertent changes
  45. (e.g. by a typo).
  46.  
  47. Option c) is to my understanding outruled by the ARM, which says that
  48. type-casting function pointers may be possible but are not further
  49. defined.(*2)
  50.  
  51. Question 2: Has the C++ standardization an opinion on function pointer
  52. casts which differ from the function's declaration only in the type
  53. qualifiers of one or more arguments?
  54.  
  55. Footnote 1: In fact, I didn't use it as solution to the problem but the
  56. problem occurred when I changed some programs to use `const' in as many
  57. places as possible, so also for function args that do not change during
  58. time.
  59.  
  60. Footnote 2: I can see a reason for this if there are different calling
  61. sequences possible (or desirable) for `f1(const int i)' and `f2(int i)'
  62. (again thanks to Jutta for this hint).
  63. -- 
  64. Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
  65.