(Note to Readers of `comp.lang.c' and `comp.lang.c++': This is a modified
repost of a question I recently posted to the above groups.  Since the
answers I received were not quite satisfactory regarding the C++ aspects,
I post it again here.)

Background: For certain reasons I'm trying to write programs in a way
so that they can be compiled with either an ANSI-C- or a C++-compiler.

Problem:  The following is the narrowed down failing case where my
C++-compiler (Comeau 3.0 on ISC UNIX) rejected some piece of code that
is valid ANSI-C (according to my SysV.R4 compiler and to Jutta Degener
who pointed out in private mail that the `const'-ness of a function's
argument is not part of the function's type in ANSI-C).

 void foo(const int i) { /* i not modified here */ }
 ...
 void (*bar)(int) = foo;

Question 1:  Has the C++ standardization already an opinion on this,
i.e. is this is an *intentional* deviation from ANSI-C?

Corretions: I see the following ways to make the program acceptable for
both, ANSI-C and C++.

 a) add `const' to bar's parameter declaration;
 b) delete `const' from foo's parameter declaration;
 c) use an explicit `(void (*)(int))'-cast in the assignment.

Option a) is of no value, since in the `real' program I need to assign
different functions to bar, some of which need non-const parameters,
hence it would just reverse the problem.

Option b) is the way I use right now(*1), but it is somewhat unsatisfactory
that I'm not able to protect foo's argument against inadvertent changes
(e.g. by a typo).

Option c) is to my understanding outruled by the ARM, which says that
type-casting function pointers may be possible but are not further
defined.(*2)

Question 2: Has the C++ standardization an opinion on function pointer
casts which differ from the function's declaration only in the type
qualifiers of one or more arguments?

Footnote 1: In fact, I didn't use it as solution to the problem but the
problem occurred when I changed some programs to use `const' in as many
places as possible, so also for function args that do not change during
time.

Footnote 2: I can see a reason for this if there are different calling
sequences possible (or desirable) for `f1(const int i)' and `f2(int i)'
(again thanks to Jutta for this hint).
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

< From: martin@mwtech.UUCP (Martin Weitzel)

< Background: For certain reasons I'm trying to write programs in a way so
< that they can be compiled with either an ANSI-C- or a C++-compiler.

< Problem:  The following is the narrowed down failing case where my
< C++-compiler (Comeau 3.0 on ISC UNIX) rejected some piece of code that is
< valid ANSI-C (according to my SysV.R4 compiler and to Jutta Degener who
< pointed out in private mail that the `const'-ness of a function's argument
< is not part of the function's type in ANSI-C).

< void foo(const int i) { /* i not modified here */ }
< ...
< void (*bar)(int) = foo;

< Question 1:  Has the C++ standardization already an opinion on this, i.e.
< is this is an *intentional* deviation from ANSI-C?

No and no. This is a topic under active discussion at this time by the
standards committee.

< Question 2: Has the C++ standardization an opinion on function pointer
< casts which differ from the function's declaration only in the type
< qualifiers of one or more arguments?

As I understnad it, the signatures must match. Whether the const is part of
the signature is what is currently under debate.

     Tony Hansen
       hansen@pegasus.att.com, tony@attmail.com
    att!pegasus!hansen, attmail!tony