lerman@stpstn.UUCP (Ken Lerman) (06/27/90)
In article <1990Jun26.145937.27988@csrd.uiuc.edu> pommerel@sp14.csrd.uiuc.edu (Claude Pommerell) writes: ...[deleted]... >I am writing portable ANSI C code, but at some points I need to insert >pragmas to use vectorization facilities of the compiler effectively. > >I would like to define a macro > #define _DIR_(p1,p2) #pragma thisdir(p1,p2) >I tried the following variants: ...[deleted]... > >7. I use the same idea as in variant 5, but run the preprocessing phase > twice, defining > #define _DIR_(p1,p2) _HASH_ pragma thisdir(p1,p2) > and calling > _DIR_(arg1,arg2) > and compiling > cc -D_HASH_=# -I. -P FILE.c > cc -c FILE.i ...[deleted]... > >Does anybody know a variant that works and is conform with the ANSI C >standard, but more elegant than the double preprocessing in variant 7 ? > > Claude Pommerell > pommy@iis.ethz.ch > or pommerel@csrd.uiuc.edu As far as I can determine, there is no way to do this in ANSI C. Your solution, (7.) is not ANSI C, because it relies on the fact that your compiler lets you run something through the preprocessor and get at the output. A -- There is no ANSI requirement that requires the ability to get at the output from the cpp. B -- Even if your compiler does have such output, there is no requirement that the output after preprocessing is a legal C program. In fact, I've seen at least two compilers where the output of cpp (after including the vendor's include files) is acceptable to the vendor's C compiler, but not to other (conforming) compilers. Unfortunately, ANSI C (also K&R C) is very weak as far as macros are concerned. It would be nice to be able to define macros within macros, ... I've heard that m4 does a decent job as a macro processor (but haven't used it). If you want to be portable, I think you'll have to add another tool to your chain. Ken
henry@utzoo.uucp (Henry Spencer) (06/27/90)
In article <1990Jun26.145937.27988@csrd.uiuc.edu> pommerel@sp14.csrd.uiuc.edu (Claude Pommerell) writes: >I am writing portable ANSI C code, but at some points I need to insert >pragmas to use vectorization facilities of the compiler effectively. > >I would like to define a macro > #define _DIR_(p1,p2) #pragma thisdir(p1,p2) There is inherently no fully portable way to do this. Section 3.8.3.4 of the Holy Writ sayeth (at the end of the discussion of macro substitution): "The resulting completely macro-replaced preprocessing token sequence is not processed as a preprocessing directive even if it resembles one." Given that section 3.8 says "The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated", and 3.8.6 on #pragma does not otherwise state, there is no fix. You can't get a #pragma as the result of a macro, and you can't rely on macro substitution inside #pragma. The C preprocessor is not a general-purpose macro processor. >7. I use the same idea as in variant 5, but run the preprocessing phase > twice, defining > #define _DIR_(p1,p2) _HASH_ pragma thisdir(p1,p2) > and calling > _DIR_(arg1,arg2) > and compiling > cc -D_HASH_=# -I. -P FILE.c > cc -c FILE.i > > At last, this seems to work. This is fairly clever, although it relies on the ability to preprocess twice, which is not guaranteed. (ANSI C does not require the ability to separate preprocessing from the rest of compilation at all.) -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John Osterhout | henry@zoo.toronto.edu utzoo!henry