Topic: #pragma and the liberty of "implementation-defined
Author: oporat@yahoo.com ("Ofer Porat")
Date: Tue, 3 Jul 2007 13:01:32 GMT Raw View
----- Original Message -----
From: "Maciej Sobczak" <see.my.homepage@gmail.com>
| Is it legal for the implementation to define that preprocessing tokens
| in #pragma *are* expanded?
I'd have to say yes because the rest of 16.6 says "The behavior might
cause translation to
fail or cause the translator or the resulting program to behave in a
non-conforming manner."
Since it's allowed to behave in a non-conforming manner, it may as well
expand macros
in that line even if the standard doesn't say that.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Maciej Sobczak <see.my.homepage@gmail.com>
Date: Fri, 29 Jun 2007 09:26:32 CST Raw View
16/4:
"The preprocessing tokens within a preprocessing directive are not
subject to macro expansion unless otherwise stated."
16.6:
"A preprocessing directive of the form
# pragma pptokensopt newline
causes the implementation to behave in an implementation-defined
manner."
Is it legal for the implementation to define that preprocessing tokens
in #pragma *are* expanded?
Is the implementation limited in what can be "implementation-defined"
in this case?
In other words:
#define SOMETHING xyz
#pragma SOMETHING
is it possible for the implementation to make the above
"work" (assuming #pragma xxx "works"), on the "implementation-defined"
basis?
--
Maciej Sobczak
http://www.msobczak.com/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]