"Dave Korn" <[EMAIL PROTECTED]> 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/
