Mail Archives: cygwin/2006/02/27/14:58:31
"Dave Korn" <dave DOT korn AT artimi DOT com> writes:
[...]
| >> OTOH it may be that libstdc++ was only supposed to be shadowing those
| >> ctype macros that are guaranteed to have underlying function
| >> implementations; I don't know what the shadowing is for, so I can't
| >> comment.
| >
| > libstdc++ is supposed to shadow ctype macros -- and it also expect
| > them to have a function implementation.
|
| Ah, does that imply it is also /supposed/ to shadow math.h macros, but it
| does /not/ expect them to have a function implementation? Or that it is /not/
| supposed to shadow math macros, only ctype ones, /because/ only they are
| guaranteed to have a function implementation as well/
The C++ rules are these:
17.4.1.2/5
Names which are defined as macros in C shall be defined as macros in
the C++ Standard Library, even if C grants license for
implementation as functions. [Note: the names defined as macros in C
include the following: assert, errno, offsetof, setjmp, va_arg,
va_end, and va_start. --end note]
17.4.1.2/6
Names that are defined as functions in C shall be defined as functions
in the C + + Standard Library.159)
footnote 159) is:
This disallows the practice, allowed in C, of providing a "masking
macro" in addition to the function prototype. The only way to
achieve equivalent "inline" behavior in C++ is to provide a
definition as an extern inline function.
libstdc++ is trying to meeting those requirements.
-- Gaby
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -