home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ulowell!m2c!bu.edu!att!cbnewsk!pegasus!hansen
- From: hansen@pegasus.att.com (Tony L. Hansen)
- Newsgroups: comp.std.c++
- Subject: Re: "const" in arglist part of function type?
- Summary: currently under investigation
- Keywords: const, function signatures
- Message-ID: <1993Jan27.173250.11596@cbnewsk.cb.att.com>
- Date: 27 Jan 93 17:32:50 GMT
- References: <1387@mwtech.UUCP>
- Sender: hansen@cbnewsk.cb.att.com (tony.l.hansen)
- Organization: AT&T
- Lines: 31
-
- < 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
-