| Title: | C++ |
| Notice: | Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS) |
| Moderator: | DECCXX::AMARTIN |
| Created: | Fri Nov 06 1987 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3604 |
| Total number of notes: | 18242 |
A customer is trying to create member function "putchar" (DEC C++
V5.3-004 on Digital UNIX V3.2 148). Some software that he uses includes
stdio.h. He ends up getting error:
cxx: Warning: xxx.C: line xx: Too many actual parameters in macro call.
Having a look at the stdio.h on my (cxx-5.5/DU4.0B) machine, I see:
#ifdef _ANSI_C_SOURCE
[...]
_BEGIN_CPLUSPLUS
[...]
extern int putchar __((int));
[...]
_END_CPLUSPLUS
[...]
#define putchar(x) putc((x), stdout)
#endif /*_ANSI_C_SOURCE */
The above defines a macro as well as an external C function, so the
macro will be expanded before any resolution to the same named member
function is attempted. Should the putchar macro definition (and
friends) be excluded for C++?
Steve
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3573.1 | I think it's a user error to try to use putchar as a member func | DECC::J_WARD | Thu May 15 1997 11:23 | 14 | |
According to the C++ standard:
"Each name defined as a macro in a header is
reserved to the implementation for any use if
the translation unit includes the header."
I believe that according to the C standard
putchar can be either defined as a function
call or a macro, it is up to the implementation.
FYI, Microsoft Visual C++ also gives an error
if you try to use the name putchar as a
member function...
| |||||
| 3573.2 | SPECXN::DERAMO | Dan D'Eramo | Thu May 15 1997 12:43 | 51 | |
However, if putchar is defined as a macro then it must be
defined as a function-like macro
#define putchar(c) ...do something with c...
as opposed to an object-like macro
extern int decc$putchar(int c);
#define putchar decc$putchar
A use of a function-like macro in the code is only an
invocation of the macro if the following preprocessing token
is a '('.
In other words, if putchar is #define'd as a function-like
macro then (putchar) does not invoke the macro. They would be
able to do
#include <stdio.h>
class MyClass {
public:
int (putchar)(int c);
};
Of course, it would also work to do
#include <stdio.h>
#undef putchar
This is something to keep in mind when trying to use any
identifier in a C++ program which is also the name of a
function in a standard C header.
Dan
X3.159-1989 section 4.1.6 page 100 ...
... Any function declared in a header may be
additionally implemented as a macro defined in the
header, so a library function should not be declared
explicitly if its header is included. Any macro
definition of a function can be suppressed locally by
enclosing the name of the function in parentheses,
because the name is then not followed by the left
parenthesis that indicates expansion of a macro
function name. For the same reason, it is permitted
to take the address of a library function even if it
is defined as a macro. ...
| |||||
| 3573.3 | CERN::CARNEY | Steve Carney | Fri May 16 1997 04:01 | 3 | |
Thanks for all the info. Steve | |||||
| 3573.4 | wishlist item | CERN::CARNEY | Steve Carney | Mon May 19 1997 12:16 | 4 |
The user understands the reply, and I said that I would forward his response: The reason of my mail was to report this inconvinience and to help the Digital's engineers to make the compiler more user-friendly. | |||||
| 3573.5 | SPECXN::DERAMO | Dan D'Eramo | Mon May 19 1997 14:18 | 13 | |
> The reason of my mail was to report this inconvinience and to help
> the Digital's engineers to make the compiler more user-friendly.
I don't think it is feasible to force every C++ user to have
to use the slower putchar() function instead of the faster
putchar() macro. I think using putchar as a member function
name is the exceptional case so that it is more user-friendly
to leave the default as it is and to require the use of #undef
or parentheses (as in .2) or perhaps some new method of
suppressing macro definitions (/define="__NO_MACROS_FOR_RTL_FUNCTIONS")
for rtl functions for the exceptional cases.
Dan
| |||||