Thread View: comp.std.c++
2 messages
2 total messages
Started by Martin Weitzel
Sun, 24 Jan 1993 17:42
"const" in arglist part of function type?
Author: Martin Weitzel
Date: Sun, 24 Jan 1993 17:42
Date: Sun, 24 Jan 1993 17:42
54 lines
2803 bytes
2803 bytes
(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
Re: "const" in arglist part of function type?
Author: Tony L. Hansen
Date: Wed, 27 Jan 1993 17:32
Date: Wed, 27 Jan 1993 17:32
31 lines
1765 bytes
1765 bytes
< 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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads