![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to cpp-2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to cpp-2 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1:
2:
3: File: cpp, Node: Argument Prescan, Next: Cascaded Macros, Prev: Self-Reference, Up: Macro Pitfalls
4:
5: Separate Expansion of Macro Arguments
6: .....................................
7:
8: We have explained that the expansion of a macro, including the substituted
9: actual arguments, is scanned over again for macro calls to be expanded.
10:
11: What really happens is more subtle: first each actual argument text is
12: scanned separately for macro calls. Then the results of this are
13: substituted into the macro body to produce the macro expansion, and the
14: macro expansion is scanned again for macros to expand.
15:
16: The result is that the actual arguments are scanned *twice* to expand macro
17: calls in them.
18:
19: Most of the time, this has no effect. If the actual argument contained any
20: macro calls, they are expanded during the first scan. The result therefore
21: contains no macro calls, so the second scan does not change it. If the
22: actual argument were substituted as given, with no prescan, the single
23: remaining scan would find the same macro calls and produce the same results.
24:
25: You might expect the double scan to change the results when a
26: self-referential macro is used in an actual argument of another macro
27: (*Note Self-Reference::.): the self-referential macro would be expanded
28: once in the first scan, and a second time in the second scan. But this is
29: not what happens. The self-references that do not expand in the first scan
30: are marked so that they will not expand in the second scan either.
31:
32: The prescan is not done when an argument is stringified or concatenated.
33: (More precisely, stringification and concatenation use the argument as
34: written, in un-prescanned form. The same actual argument would be used in
35: prescanned form if it is substituted elsewhere without stringification or
36: concatenation.) Thus,
37:
38: #define str(s) #s
39: #define foo 4
40: str (foo)
41:
42: expands to `"foo"'. Once more, prescan has been prevented from having any
43: noticeable effect.
44:
45: You might now ask, ``Why mention the prescan, if it makes no difference?
46: Why not skip it and make the preprocessor faster?'' The answer is that the
47: prescan does make a difference in two special cases:
48:
49: * Nested calls to a macro.
50:
51: * Macros that call other macros that stringify or concatenate.
52:
53: We say that "nested" calls to a macro occur when a macro's actual argument
54: contains a call to that very macro. For example, if `f' is a macro that
55: expects one argument, `f (f (1))' is a nested pair of calls to `f'. The
56: desired expansion is made by expanding `f (1)' and substituting that into
57: the definition of `f'. The prescan causes the expected result to happen.
58: Without the prescan, `f (1)' itself would be substituted as an actual
59: argument, and the inner use of `f' would appear during the main scan as an
60: indirect self-reference and would not be expanded. Here, the prescan
61: cancels an undesirable side effect (in the medical, not computational,
62: sense of the term) of the special rule for self-referential macros.
63:
64: There is also one case where prescan is useful. It is possible to use
65: prescan to expand an argument and then stringify it---if you use two levels
66: of macros. Let's add a new macro `xstr' to the example shown above:
67:
68: #define xstr(s) str(s)
69: #define str(s) #s
70: #define foo 4
71: xstr (foo)
72:
73: This expands into `"4"', not `"foo"'. The reason for the difference is
74: that the argument of `xstr' is expanded at prescan (because `xstr' does not
75: specify stringification or concatenation of the argument). The result of
76: prescan then forms the actual argument for `str'. `str' uses its argument
77: without prescan because it performs strigification; but it cannot prevent
78: or undo the prescanning already done by `xstr'.
79:
80:
81: File: cpp, Node: Cascaded Macros, Prev: Argument Prescan, Up: Macro Pitfalls
82:
83: Cascaded Use of Macros
84: ......................
85:
86: A "cascade" of macros is when one macro's body contains a reference to
87: another macro. This is very common practice. For example,
88:
89: #define BUFSIZE 1020
90: #define TABLESIZE BUFSIZE
91:
92: This is not at all the same as defining `TABLESIZE' to be `1020'. The
93: `#define' for `TABLESIZE' uses exactly the body you specify---in this case,
94: `BUFSIZE'---and does not check to see whether it too is the name of a macro.
95:
96: It's only when you *use* `TABLESIZE' that the result of its expansion is
97: checked for more macro names.
98:
99: This makes a difference if you change the definition of `BUFSIZE' at some
100: point in the source file. `TABLESIZE', defined as shown, will always
101: expand using the definition of `BUFSIZE' that is currently in effect:
102:
103: #define BUFSIZE 1020
104: #define TABLESIZE BUFSIZE
105: #undef BUFSIZE
106: #define BUFSIZE 37
107:
108: Now `TABLESIZE' expands (in two stages) to `37'.
109:
110:
111: File: cpp, Node: Conditionals, Next: Combining Sources, Prev: Macros, Up: Top
112:
113: Conditionals
114: ============
115:
116: In a macro processor, a "conditional" is a command that allows a part of
117: the program to be ignored during compilation, on some conditions. In the C
118: preprocessor, a conditional can test either an arithmetic expression or
119: whether a name is defined as a macro.
120:
121: A conditional in the C preprocessor resembles in some ways an `if'
122: statement in C, but it is important to understand the difference between
123: them. The condition in an `if' statement is tested during the execution of
124: your program. Its purpose is to allow your program to behave differently
125: from run to run, depending on the data it is operating on. The condition
126: in a preprocessor conditional command is tested when your program is
127: compiled. Its purpose is to allow different code to be included in the
128: program depending on the situation at the time of compilation.
129:
130: * Menu:
131:
132: * Uses: Conditional Uses. What conditionals are for.
133: * Syntax: Conditional Syntax. How conditionals are written.
134: * Deletion: Deleted Code. Making code into a comment.
135: * Macros: Conditionals-Macros. Why conditionals are used with macros.
136: * Errors: #error Command. Detecting inconsistent compilation parameters.
137:
138:
139:
140: File: cpp, Node: Conditional Uses, Next: Conditional Syntax, Prev: Conditionals, Up: Conditionals
141:
142: Generally there are three kinds of reason to use a conditional.
143:
144: * A program may need to use different code depending on the machine or
145: operating system it is to run on. In some cases the code for one
146: operating system may be erroneous on another operating system; for
147: example, it might refer to library routines that do not exist on the
148: other system. When this happens, it is not enough to avoid executing
149: the invalid code: merely having it in the program makes it impossible
150: to link the program and run it. With a preprocessor conditional, the
151: offending code can be effectively excised from the program when it is
152: not valid.
153:
154: * You may want to be able to compile the same source file into two
155: different programs. Sometimes the difference between the programs is
156: that one makes frequent time-consuming consistency checks on its
157: intermediate data while the other does not.
158:
159: * A conditional whose condition is always false is a good way to exclude
160: code from the program but keep it as a sort of comment for future
161: reference.
162:
163: Most simple programs that are intended to run on only one machine will not
164: need to use preprocessor conditionals.
165:
166:
167: File: cpp, Node: Conditional Syntax, Next: Conditionals-Macros, Prev: Conditional Uses, Up: Conditionals
168:
169: Syntax of Conditionals
170: ----------------------
171:
172: A conditional in the C preprocessor begins with a "conditional command":
173: `#if', `#ifdef' or `#ifndef'.*note Conditionals::, for info on `#ifdef' and
174: `#ifndef'; only `#if' is explained here.
175:
176: * Menu:
177:
178: * If: #if Command. Basic conditionals using `#if' and `#endif'.
179: * Else: #else Command. Including some text if the condition fails.
180: * Elif: #elif Command. Testing several alternative possibilities.
181:
182:
183:
184: File: cpp, Node: #if Command, Next: #else Command, Prev: Conditional Syntax, Up: Conditional Syntax
185:
186: The `#if' Command
187: .................
188:
189: The `#if' command in its simplest form consists of
190:
191: #if EXPRESSION
192: CONTROLLED TEXT
193: #endif /* EXPRESSION */
194:
195: The comment following the `#endif' is not required, but it is a good
196: practice because it helps people match the `#endif' to the corresponding
197: `#if'. Such comments should always be used, except in short conditionals
198: that are not nested. In fact, you can put anything at all after the
199: `#endif' and it will be ignored by the GNU C preprocessor, but only
200: comments are acceptable in ANSI Standard C.
201:
202: EXPRESSION is a C expression of integer type, subject to stringent
203: restrictions. It may contain
204:
205: * Integer constants, which are all regarded as `long' or `unsigned long'.
206:
207: * Character constants, which are interpreted according to the character
208: set and conventions of the machine and operating system on which the
209: preprocessor is running. The GNU C preprocessor uses the C data type
210: `char' for these character constants; therefore, whether some
211: character codes are negative is determined by the C compiler used to
212: compile the preprocessor. If it treats `char' as signed, then
213: character codes large enough to set the sign bit will be considered
214: negative; otherwise, no character code is considered negative.
215:
216: * Arithmetic operators for addition, subtraction, multiplication,
217: division, bitwise operations, shifts, comparisons, and `&&' and `||'.
218:
219: * Identifiers that are not macros, which are all treated as zero(!).
220:
221: * Macro calls. All macro calls in the expression are expanded before
222: actual computation of the expression's value begins.
223:
224: Note that `sizeof' operators and `enum'-type values are not allowed.
225: `enum'-type values, like all other identifiers that are not taken as macro
226: calls and expanded, are treated as zero.
227:
228: The text inside of a conditional can include preprocessor commands. Then
229: the commands inside the conditional are obeyed only if that branch of the
230: conditional succeeds. The text can also contain other conditional groups.
231: However, the `#if''s and `#endif''s must balance.
232:
233:
234: File: cpp, Node: #else Command, Next: #elif Command, Prev: #if Command, Up: Conditional Syntax
235:
236: The `#else' Command
237: ...................
238:
239: The `#else' command can be added a conditional to provide alternative text
240: to be used if the condition is false. This looks like
241:
242: #if EXPRESSION
243: TEXT-IF-TRUE
244: #else /* Not EXPRESSION */
245: TEXT-IF-FALSE
246: #endif /* Not EXPRESSION */
247:
248: If EXPRESSION is nonzero, and the TEXT-IF-TRUE is considered included, then
249: `#else' acts like a failing conditional and the TEXT-IF-FALSE is ignored.
250: Contrariwise, if the `#if' conditional fails, the TEXT-IF-FALSE is
251: considered included.
252:
253:
254: File: cpp, Node: #elif Command, Prev: #else Command, Up: Conditional Syntax
255:
256: The `#elif' Command
257: ...................
258:
259: One common case of nested conditionals is used to check for more than two
260: possible alternatives. For example, you might have
261:
262: #if X == 1
263: ...
264: #else /* X != 1 */
265: #if X == 2
266: ...
267: #else /* X != 2 */
268: ...
269: #endif /* X != 2 */
270: #endif /* X != 1 */
271:
272: Another conditional command, `#elif', allows this to be abbreviated as
273: follows:
274:
275: #if X == 1
276: ...
277: #elif X == 2
278: ...
279: #else /* X != 2 and X != 1*/
280: ...
281: #endif /* X != 2 and X != 1*/
282:
283: `#elif' stands for ``else if''. Like `#else', it goes in the middle of a
284: `#if'-`#endif' pair and subdivides it; it does not require a matching
285: `#endif' of its own. Like `#if', the `#elif' command includes an
286: expression to be tested.
287:
288: The text following the `#elif' is processed only if the original
289: `#if'-condition failed and the `#elif' condition succeeeds. More than one
290: `#elif' can go in the same `#if'-`#endif' group. Then the text after each
291: `#elif' is processed only if the `#elif' condition succeeds after the
292: original `#if' and any previous `#elif''s within it have failed. `#else'
293: is equivalent to `#elif 1', and `#else' is allowed after any number of
294: `#elif''s, but `#elif' may not follow a `#else'.
295:
296:
297: File: cpp, Node: Deleted Code, Next: Conditionals-Macros, Prev: Conditional Syntax, Up: Conditionals
298:
299: Keeping Deleted Code for Future Reference
300: -----------------------------------------
301:
302: If you replace or delete a part of the program but want to keep the old
303: code around as a comment for future reference, the easy way to do this is
304: to put `#if 0' before it and `#endif' after it.
305:
306: This works even if the code being turned off contains conditionals, but
307: they must be entire conditionals (balanced `#if' and `#endif').
308:
309:
310: File: cpp, Node: Conditionals-Macros, Next: #error Command, Prev: Deleted Code, Up: Conditionals
311:
312: Conditionals and Macros
313: -----------------------
314:
315: Conditionals are rarely useful except in connection with macros. A `#if'
316: command whose expression uses no macros is equivalent to `#if 1' or `#if
317: 0'; you might as well determine which one, by computing the value of the
318: expression yourself, and then simplify the program. But when the
319: expression uses macros, its value can vary from compilation to compilation.
320:
321: For example, here is a conditional that tests the expression `BUFSIZE ==
322: 1020', where `BUFSIZE' must be a macro.
323:
324: #if BUFSIZE == 1020
325: printf ("Large buffers!\n");
326: #endif /* BUFSIZE is large */
327:
328: The special operator `defined' may be used in `#if' expressions to test
329: whether a certain name is defined as a macro. Either `defined NAME' or
330: `defined (NAME)' is an expression whose value is 1 if NAME is defined as
331: macro at the current point in the program, and 0 otherwise. For the
332: `defined' operator it makes no difference what the definition of the macro
333: is; all that matters is whether there is a definition. Thus, for example,
334:
335: #if defined (vax) || defined (ns16000)
336:
337: would include the following code if either of the names `vax' and `ns16000'
338: is defined as a macro.
339:
340: If a macro is defined and later undefined with `#undef', subsequent use of
341: the `defined' operator will return 0, because the name is no longer
342: defined. If the macro is defined again with another `#define', `defined'
343: will recommence returning 1.
344:
345: Conditionals that test just the definedness of one name are very common, so
346: there are two special short conditional commands for this case. They are
347:
348: `#ifdef NAME'
349: is equivalent to `#if defined (NAME)'.
350:
351: `#ifndef NAME'
352: is equivalent to `#if ! defined (NAME)'.
353:
354: Macro definitions can vary between compilations for several reasons.
355:
356: * Some macros are predefined on each kind of machine. For example, on a
357: Vax, the name `vax' is a predefined macro. On other machines, it
358: would not be defined.
359:
360: * Many more macros are defined by system header files. Different
361: systems and machines define different macros, or give them different
362: values. It is useful to test these macros with conditionals to avoid
363: using a system feature on a machine where it is not implemented.
364:
365: * Macros are a common way of allowing users to customize a program for
366: different machines or applications. For example, the macro `BUFSIZE'
367: might be defined in a configuration file for your program that is
368: included as a header file in each source file. You would use
369: `BUFSIZE' in a preprocessor conditional in order to generate different
370: code depending on the chosen configuration.
371:
372: * Macros can be defined or undefined with `-D' and `-U' command options
373: when you compile the program. You can arrange to compile the same
374: source file into two different programs by choosing a macro name to
375: specify which program you want, writing conditionals to test whether
376: or how this macro is defined, and then controlling the state of the
377: macro with compiler command options. *note Invocation::.
378:
379:
380: File: cpp, Node: #error Command, Prev: Conditionals-Macros, Up: Conditionals
381:
382: The `#error' Command
383: --------------------
384:
385: The command `#error' causes the preprocessor to report a fatal error. The
386: rest of the line that follows `#error' is used as the error message.
387:
388: You would use `#error' inside of a conditional that detects a combination
389: of parameters which you know the program does not properly support. For
390: example, if you know that the program will not run properly on a Vax, you
391: might write
392:
393: #ifdef vax
394: #error Won't work on Vaxen. See comments at get_last_object.
395: #endif
396:
397: *note Nonstandard Predefined::, for why this works.
398:
399: If you have several configuration parameters that must be set up by the
400: installation in a consistent way, you can use conditionals to detect an
401: inconsistency and report it with `#error'. For example,
402:
403: #if HASH_TABLE_SIZE % 2 == 0 || HASH_TABLE_SIZE % 3 == 0 \
404: || HASH_TABLE_SIZE % 5 == 0
405: #error HASH_TABLE_SIZE should not be divisible by a small prime
406: #endif
407:
408:
409: File: cpp, Node: Combining Sources, Next: Other Commands, Prev: Conditionals, Up: Top
410:
411: Combining Source Files
412: ======================
413:
414: One of the jobs of the C preprocessor is to inform the C compiler of where
415: each line of C code came from: which source file and which line number.
416:
417: C code can come from multiple source files if you use `#include'; both
418: `#include' and the use of conditionals and macros can cause the line number
419: of a line in the preprocessor output to be different from the line's number
420: in the original source file. You will appreciate the value of making both
421: the C compiler (in error messages) and symbolic debuggers such as GDB use
422: the line numbers in your source file.
423:
424: The C preprocessor builds on this feature by offering a command by which
425: you can control the feature explicitly. This is useful when a file for
426: input to the C preprocessor is the output from another program such as the
427: `bison' parser generator, which operates on another file that is the true
428: source file. Parts of the output from `bison' are generated from scratch,
429: other parts come from a standard parser file. The rest are copied nearly
430: verbatim from the source file, but their line numbers in the `bison' output
431: are not the same as their original line numbers. Naturally you would like
432: compiler error messages and symbolic debuggers to know the original source
433: file and line number of each line in the `bison' output.
434:
435: `bison' arranges this by writing `#line' commands into the output file.
436: `#line' is a command that specifies the original line number and source
437: file name for subsequent input in the current preprocessor input file.
438: `#line' has three variants:
439:
440: `#line LINENUM'
441: Here LINENUM is a decimal integer constant. This specifies that the
442: line number of the following line of input, in its original source
443: file, was LINENUM.
444:
445: `#line LINENUM FILENAME'
446: Here LINENUM is a decimal integer constant and FILENAME is a string
447: constant. This specifies that the following line of input came
448: originally from source file FILENAME and its line number there was
449: LINENUM. Keep in mind that FILENAME is not just a file name; it is
450: surrounded by doublequote characters so that it looks like a string
451: constant.
452:
453: `#line ANYTHING ELSE'
454: ANYTHING ELSE is checked for macro calls, which are expanded. The
455: result should be a decimal integer constant followed optionally by a
456: string constant, as described above.
457:
458: `#line' commands alter the results of the `__FILE__' and `__LINE__'
459: predefined macros from that point on. *note Standard Predefined::.
460:
461:
462: File: cpp, Node: Other Commands, Next: Output, Prev: Combining Sources, Up: Top
463:
464: Miscellaneous Preprocessor Commands
465: ===================================
466:
467: This section describes two additional preprocesor commands. They are not
468: very useful, but are mentioned for completeness.
469:
470: The "null command" consists of a `#' followed by a Newline, with only
471: whitespace (including comments) in between. A null command is understood
472: as a preprocessor command but has no effect on the preprocessor output.
473: The primary significance of the existence of the null command is that an
474: input line consisting of just a `#' will produce no output, rather than a
475: line of output containing just a `#'. Supposedly some old C programs
476: contain such lines.
477:
478: The `#pragma' command is specified in the ANSI standard to have an
479: arbitrary implementation-defined effect. In the GNU C preprocessor,
480: `#pragma' first attempts to run the game `rogue'; if that fails, it tries
481: to run the game `hack'; if that fails, it tries to run GNU Emacs displaying
482: the Tower of Hanoi; if that fails, it reports a fatal error. In any case,
483: preprocessing does not continue.
484:
485:
486: File: cpp, Node: Output, Next: Invocation, Prev: Other Commands, Up: Top
487:
488: C Preprocessor Output
489: =====================
490:
491: The output from the C preprocessor looks much like the input, except that
492: all preprocessor command lines have been replaced with blank lines and all
493: comments with spaces. Whitespace within a line is not altered; however, a
494: space is inserted after the expansions of most macro calls.
495:
496: Source file name and line number information is conveyed by lines of the form
497:
498: # LINENUM FILENAME
499:
500: which are inserted as needed into the middle of the input (but never within
501: a string or character constant). Such a line means that the following line
502: originated in file FILENAME at line LINENUM.
503:
504:
505: File: cpp, Node: Invocation, Prev: Output, Up: Top
506:
507: Invoking the C Preprocessor
508: ===========================
509:
510: Most often when you use the C preprocessor you will not have to invoke it
511: explicitly: the C compiler will do so automatically. However, the
512: preprocessor is sometimes useful individually.
513:
514: The C preprocessor expects two file names as arguments, INFILE and OUTFILE.
515: The preprocessor reads INFILE together with any other files it specifies
516: with `#include'. All the output generated by the combined input files is
517: written in OUTFILE.
518:
519: Either INFILE or OUTFILE may be `-', which as INFILE means to read from
520: standard input and as OUTFILE means to write to standard output. Also, if
521: OUTFILE or both file names are omitted, the standard output and standard
522: input are used for the omitted file names.
523:
524: Here is a table of command options accepted by the C preprocessor. Most of
525: them can also be given when compiling a C program; they are passed along
526: automatically to the preprocessor when it is invoked by the compiler.
527:
528: `-P'
529: Inhibit generation of `#'-lines with line-number information in the
530: output from the preprocessor (*Note Output::.). This might be useful
531: when running the preprocessor on something that is not C code and will
532: be sent to a program which might be confused by the `#'-lines
533:
534: `-C'
535: Do not discard comments: pass them through to the output file.
536: Comments appearing in arguments of a macro call will be copied to the
537: output before the expansion of the macro call.
538:
539: `-T'
540: Process ANSI standard trigraph sequences. These are three-character
541: sequences, all starting with `??', that are defined by ANSI C to stand
542: for single characters. For example, `??/' stands for `\', so `'??/n''
543: is a character constant for Newline. Strictly speaking, the GNU C
544: preprocessor does not support all programs in ANSI Standard C unless
545: `-T' is used, but if you ever notice the difference it will be with
546: relief.
547:
548: You don't want to know any more about trigraphs.
549:
550: `-pedantic'
551: Issue warnings required by the ANSI C standard in certain cases such
552: as when text other than a comment follows `#else' or `#endif'.
553:
554: `-I DIRECTORY'
555: Add the directory DIRECTORY to the end of the list of directories to
556: be searched for header files (*Note Include Syntax::.). This can be
557: used to override a system header file, substituting your own version,
558: since these directories are searched before the system header file
559: directories. If you use more than one `-I' option, the directories
560: are scanned in left-to-right order; the standard system directories
561: come after.
562:
563: `-I-'
564: Any directories specified with `-I' options before the `-I-' option
565: are searched only for the case of `#include "FILE"'; they are not
566: searched for `#include <FILE>'.
567:
568: If additional directories are specified with `-I' options after the
569: `-I-', these directories are searched for all `#include' directives.
570:
571: In addition, the `-I-' option inhibits the use of the current
572: directory as the first search directory for `#include "FILE"'.
573: Therefore, the current directory is searched only if it is requested
574: explicitly with `-I.'. Specifying both `-I-' and `-I.' allows you to
575: control precisely which directories are searched before the current
576: one and which are searched after.
577:
578: `-nostdinc'
579: Do not search the standard system directories for header files. Only
580: the directories you have specified with `-I' options (and the current
581: directory, if appropriate) are searched.
582:
583: `-D NAME'
584: Predefine NAME as a macro, with definition `1'.
585:
586: `-D NAME=DEFINITION'
587: Predefine NAME as a macro, with definition DEFINITION. There are no
588: restrictions on the contents of DEFINITION, but if you are invoking
589: the preprocessor from a shell or shell-like program you may need to
590: use the shell's quoting syntax to protect characters such as spaces
591: that have a meaning in the shell syntax.
592:
593: `-U NAME'
594: Do not predefine NAME. If both `-U' and `-D' are specified for one
595: name, the `-U' beats the `-D' and the name is not predefined.
596:
597: `-undef'
598: Do not predefine any nonstandard macros.
599:
600: `-d'
601: Instead of outputting the result of preprocessing, output a list of
602: `#define' commands for all the macros defined during the execution of
603: the preprocessor.
604:
605: `-M'
606: Instead of outputting the result of preprocessing, output a rule
607: suitable for `make' describing the dependencies of the main source
608: file. The preprocessor outputs one `make' rule containing the object
609: file name for that source file, a colon, and the names of all the
610: included files. If there are many included files then the rule is
611: split into several lines using `\'-newline.
612:
613: This feature is used in automatic updating of makefiles.
614:
615: `-MM'
616: Like `-M' but mention only the files included with `#include "FILE"'.
617: System header files included with `#include <FILE>' are omitted.
618:
619: `-i FILE'
620: Process FILE as input, discarding the resulting output, before
621: processing the regular input file. Because the output generated from
622: FILE is discarded, the only effect of `-i FILE' is to make the macros
623: defined in FILE available for use in the main input.
624:
625:
626: File: cpp, Node: Concept Index, Next: Index, Prev: Invocation, Up: Top
627:
628: Concept Index
629: *************
630:
631: * Menu:
632:
633: * cascaded macros: Cascaded Macros.
634: * commands: Commands.
635: * concatenation: Concatenation.
636: * conditionals: Conditionals.
637: * header file: Header Files.
638: * line control: Combining Sources.
639: * macro body uses macro: Cascaded Macros.
640: * null command: Other Commands.
641: * options: Invocation.
642: * output format: Output.
643: * predefined macros: Predefined.
644: * preprocessor commands: Commands.
645: * redefining macros: Redefining.
646: * self-reference: Self-Reference.
647: * semicolons (after macro calls): Swallow Semicolon.
648: * side effects (in macro arguments): Side Effects.
649: * stringification: Stringification.
650: * undefining macros: Undefining.
651: * unsafe macros: Side Effects.
652:
653:
654: File: cpp, Node: Index, Prev: Concept Index, Up: Top
655:
656: Index of Commands, Macros and Options
657: *************************************
658:
659: * Menu:
660:
661: * #elif: #elif Command.
662: * #else: #else Command.
663: * #error: #error Command.
664: * #if: Conditional Syntax.
665: * #ifdef: Conditionals-Macros.
666: * #ifndef: Conditionals-Macros.
667: * #include: Include Syntax.
668: * #line: Combining Sources.
669: * #pragma: Other Commands.
670: * -C: Invocation.
671: * -D: Invocation.
672: * -I: Invocation.
673: * -M: Invocation.
674: * -MM: Invocation.
675: * -P: Invocation.
676: * -T: Invocation.
677: * -U: Invocation.
678: * -d: Invocation.
679: * -i: Invocation.
680: * -pedantic: Invocation.
681: * -undef: Invocation.
682: * BSD: Nonstandard Predefined.
683: * M68020: Nonstandard Predefined.
684: * __DATE__: Standard Predefined.
685: * __FILE__: Standard Predefined.
686: * __LINE__: Standard Predefined.
687: * __STDC__: Standard Predefined.
688: * __TIME__: Standard Predefined.
689: * defined: Conditionals-Macros.
690: * m68k: Nonstandard Predefined.
691: * mc68000: Nonstandard Predefined.
692: * ns32000: Nonstandard Predefined.
693: * pyr: Nonstandard Predefined.
694: * sequent: Nonstandard Predefined.
695: * sun: Nonstandard Predefined.
696: * system header files: Header Uses.
697: * unix: Nonstandard Predefined.
698: * vax: Nonstandard Predefined.
699:
700:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.