]>
Commit | Line | Data |
---|---|---|
336b436a JL |
1 | This is Info file gcc.info, produced by Makeinfo version 1.68 from the |
2 | input file gcc.texi. | |
3 | ||
4 | This file documents the use and the internals of the GNU compiler. | |
5 | ||
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 | |
7 | Boston, MA 02111-1307 USA | |
8 | ||
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free | |
10 | Software Foundation, Inc. | |
11 | ||
12 | Permission is granted to make and distribute verbatim copies of this | |
13 | manual provided the copyright notice and this permission notice are | |
14 | preserved on all copies. | |
15 | ||
16 | Permission is granted to copy and distribute modified versions of | |
17 | this manual under the conditions for verbatim copying, provided also | |
18 | that the sections entitled "GNU General Public License," "Funding for | |
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are | |
20 | included exactly as in the original, and provided that the entire | |
21 | resulting derived work is distributed under the terms of a permission | |
22 | notice identical to this one. | |
23 | ||
24 | Permission is granted to copy and distribute translations of this | |
25 | manual into another language, under the above conditions for modified | |
26 | versions, except that the sections entitled "GNU General Public | |
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight | |
28 | `Look And Feel'", and this permission notice, may be included in | |
29 | translations approved by the Free Software Foundation instead of in the | |
30 | original English. | |
31 | ||
32 | \1f | |
33 | File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: C Extensions | |
34 | ||
35 | An Inline Function is As Fast As a Macro | |
36 | ======================================== | |
37 | ||
38 | By declaring a function `inline', you can direct GNU CC to integrate | |
39 | that function's code into the code for its callers. This makes | |
40 | execution faster by eliminating the function-call overhead; in | |
41 | addition, if any of the actual argument values are constant, their known | |
42 | values may permit simplifications at compile time so that not all of the | |
43 | inline function's code needs to be included. The effect on code size is | |
44 | less predictable; object code may be larger or smaller with function | |
45 | inlining, depending on the particular case. Inlining of functions is an | |
46 | optimization and it really "works" only in optimizing compilation. If | |
47 | you don't use `-O', no function is really inline. | |
48 | ||
49 | To declare a function inline, use the `inline' keyword in its | |
50 | declaration, like this: | |
51 | ||
52 | inline int | |
53 | inc (int *a) | |
54 | { | |
55 | (*a)++; | |
56 | } | |
57 | ||
58 | (If you are writing a header file to be included in ANSI C programs, | |
59 | write `__inline__' instead of `inline'. *Note Alternate Keywords::.) | |
60 | ||
61 | You can also make all "simple enough" functions inline with the | |
62 | option `-finline-functions'. Note that certain usages in a function | |
63 | definition can make it unsuitable for inline substitution. | |
64 | ||
65 | Note that in C and Objective C, unlike C++, the `inline' keyword | |
66 | does not affect the linkage of the function. | |
67 | ||
68 | GNU CC automatically inlines member functions defined within the | |
69 | class body of C++ programs even if they are not explicitly declared | |
70 | `inline'. (You can override this with `-fno-default-inline'; *note | |
71 | Options Controlling C++ Dialect: C++ Dialect Options..) | |
72 | ||
73 | When a function is both inline and `static', if all calls to the | |
74 | function are integrated into the caller, and the function's address is | |
75 | never used, then the function's own assembler code is never referenced. | |
76 | In this case, GNU CC does not actually output assembler code for the | |
77 | function, unless you specify the option `-fkeep-inline-functions'. | |
78 | Some calls cannot be integrated for various reasons (in particular, | |
79 | calls that precede the function's definition cannot be integrated, and | |
80 | neither can recursive calls within the definition). If there is a | |
81 | nonintegrated call, then the function is compiled to assembler code as | |
82 | usual. The function must also be compiled as usual if the program | |
83 | refers to its address, because that can't be inlined. | |
84 | ||
85 | When an inline function is not `static', then the compiler must | |
86 | assume that there may be calls from other source files; since a global | |
87 | symbol can be defined only once in any program, the function must not | |
88 | be defined in the other source files, so the calls therein cannot be | |
89 | integrated. Therefore, a non-`static' inline function is always | |
90 | compiled on its own in the usual fashion. | |
91 | ||
92 | If you specify both `inline' and `extern' in the function | |
93 | definition, then the definition is used only for inlining. In no case | |
94 | is the function compiled on its own, not even if you refer to its | |
95 | address explicitly. Such an address becomes an external reference, as | |
96 | if you had only declared the function, and had not defined it. | |
97 | ||
98 | This combination of `inline' and `extern' has almost the effect of a | |
99 | macro. The way to use it is to put a function definition in a header | |
100 | file with these keywords, and put another copy of the definition | |
101 | (lacking `inline' and `extern') in a library file. The definition in | |
102 | the header file will cause most calls to the function to be inlined. | |
103 | If any uses of the function remain, they will refer to the single copy | |
104 | in the library. | |
105 | ||
106 | GNU C does not inline any functions when not optimizing. It is not | |
107 | clear whether it is better to inline or not, in this case, but we found | |
108 | that a correct implementation when not optimizing was difficult. So we | |
109 | did the easy thing, and turned it off. | |
110 | ||
111 | \1f | |
112 | File: gcc.info, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: C Extensions | |
113 | ||
114 | Assembler Instructions with C Expression Operands | |
115 | ================================================= | |
116 | ||
117 | In an assembler instruction using `asm', you can now specify the | |
118 | operands of the instruction using C expressions. This means no more | |
119 | guessing which registers or memory locations will contain the data you | |
120 | want to use. | |
121 | ||
122 | You must specify an assembler instruction template much like what | |
123 | appears in a machine description, plus an operand constraint string for | |
124 | each operand. | |
125 | ||
126 | For example, here is how to use the 68881's `fsinx' instruction: | |
127 | ||
128 | asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); | |
129 | ||
130 | Here `angle' is the C expression for the input operand while `result' | |
131 | is that of the output operand. Each has `"f"' as its operand | |
132 | constraint, saying that a floating point register is required. The `=' | |
133 | in `=f' indicates that the operand is an output; all output operands' | |
134 | constraints must use `='. The constraints use the same language used | |
135 | in the machine description (*note Constraints::.). | |
136 | ||
137 | Each operand is described by an operand-constraint string followed | |
138 | by the C expression in parentheses. A colon separates the assembler | |
139 | template from the first output operand, and another separates the last | |
140 | output operand from the first input, if any. Commas separate output | |
141 | operands and separate inputs. The total number of operands is limited | |
142 | to ten or to the maximum number of operands in any instruction pattern | |
143 | in the machine description, whichever is greater. | |
144 | ||
145 | If there are no output operands, and there are input operands, then | |
146 | there must be two consecutive colons surrounding the place where the | |
147 | output operands would go. | |
148 | ||
149 | Output operand expressions must be lvalues; the compiler can check | |
150 | this. The input operands need not be lvalues. The compiler cannot | |
151 | check whether the operands have data types that are reasonable for the | |
152 | instruction being executed. It does not parse the assembler | |
153 | instruction template and does not know what it means, or whether it is | |
154 | valid assembler input. The extended `asm' feature is most often used | |
155 | for machine instructions that the compiler itself does not know exist. | |
156 | If the output expression cannot be directly addressed (for example, it | |
157 | is a bit field), your constraint must allow a register. In that case, | |
158 | GNU CC will use the register as the output of the `asm', and then store | |
159 | that register into the output. | |
160 | ||
161 | The ordinary output operands must be write-only; GNU CC will assume | |
162 | that the values in these operands before the instruction are dead and | |
163 | need not be generated. Extended asm supports input-output or | |
164 | read-write operands. Use the constraint character `+' to indicate such | |
165 | an operand and list it with the output operands. | |
166 | ||
167 | When the constraints for the read-write operand (or the operand in | |
168 | which only some of the bits are to be changed) allows a register, you | |
169 | may, as an alternative, logically split its function into two separate | |
170 | operands, one input operand and one write-only output operand. The | |
171 | connection between them is expressed by constraints which say they need | |
172 | to be in the same location when the instruction executes. You can use | |
173 | the same C expression for both operands, or different expressions. For | |
174 | example, here we write the (fictitious) `combine' instruction with | |
175 | `bar' as its read-only source operand and `foo' as its read-write | |
176 | destination: | |
177 | ||
178 | asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); | |
179 | ||
180 | The constraint `"0"' for operand 1 says that it must occupy the same | |
181 | location as operand 0. A digit in constraint is allowed only in an | |
182 | input operand, and it must refer to an output operand. | |
183 | ||
184 | Only a digit in the constraint can guarantee that one operand will | |
185 | be in the same place as another. The mere fact that `foo' is the value | |
186 | of both operands is not enough to guarantee that they will be in the | |
187 | same place in the generated assembler code. The following would not | |
188 | work: | |
189 | ||
190 | asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar)); | |
191 | ||
192 | Various optimizations or reloading could cause operands 0 and 1 to | |
193 | be in different registers; GNU CC knows no reason not to do so. For | |
194 | example, the compiler might find a copy of the value of `foo' in one | |
195 | register and use it for operand 1, but generate the output operand 0 in | |
196 | a different register (copying it afterward to `foo''s own address). Of | |
197 | course, since the register for operand 1 is not even mentioned in the | |
198 | assembler code, the result will not work, but GNU CC can't tell that. | |
199 | ||
200 | Some instructions clobber specific hard registers. To describe | |
201 | this, write a third colon after the input operands, followed by the | |
202 | names of the clobbered hard registers (given as strings). Here is a | |
203 | realistic example for the Vax: | |
204 | ||
205 | asm volatile ("movc3 %0,%1,%2" | |
206 | : /* no outputs */ | |
207 | : "g" (from), "g" (to), "g" (count) | |
208 | : "r0", "r1", "r2", "r3", "r4", "r5"); | |
209 | ||
210 | If you refer to a particular hardware register from the assembler | |
211 | code, then you will probably have to list the register after the third | |
212 | colon to tell the compiler that the register's value is modified. In | |
213 | many assemblers, the register names begin with `%'; to produce one `%' | |
214 | in the assembler code, you must write `%%' in the input. | |
215 | ||
216 | If your assembler instruction can alter the condition code register, | |
217 | add `cc' to the list of clobbered registers. GNU CC on some machines | |
218 | represents the condition codes as a specific hardware register; `cc' | |
219 | serves to name this register. On other machines, the condition code is | |
220 | handled differently, and specifying `cc' has no effect. But it is | |
221 | valid no matter what the machine. | |
222 | ||
223 | If your assembler instruction modifies memory in an unpredictable | |
224 | fashion, add `memory' to the list of clobbered registers. This will | |
225 | cause GNU CC to not keep memory values cached in registers across the | |
226 | assembler instruction. | |
227 | ||
228 | You can put multiple assembler instructions together in a single | |
229 | `asm' template, separated either with newlines (written as `\n') or with | |
230 | semicolons if the assembler allows such semicolons. The GNU assembler | |
231 | allows semicolons and all Unix assemblers seem to do so. The input | |
232 | operands are guaranteed not to use any of the clobbered registers, and | |
233 | neither will the output operands' addresses, so you can read and write | |
234 | the clobbered registers as many times as you like. Here is an example | |
235 | of multiple instructions in a template; it assumes that the subroutine | |
236 | `_foo' accepts arguments in registers 9 and 10: | |
237 | ||
238 | asm ("movl %0,r9;movl %1,r10;call _foo" | |
239 | : /* no outputs */ | |
240 | : "g" (from), "g" (to) | |
241 | : "r9", "r10"); | |
242 | ||
243 | Unless an output operand has the `&' constraint modifier, GNU CC may | |
244 | allocate it in the same register as an unrelated input operand, on the | |
245 | assumption that the inputs are consumed before the outputs are produced. | |
246 | This assumption may be false if the assembler code actually consists of | |
247 | more than one instruction. In such a case, use `&' for each output | |
248 | operand that may not overlap an input. *Note Modifiers::. | |
249 | ||
250 | If you want to test the condition code produced by an assembler | |
251 | instruction, you must include a branch and a label in the `asm' | |
252 | construct, as follows: | |
253 | ||
254 | asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:" | |
255 | : "g" (result) | |
256 | : "g" (input)); | |
257 | ||
258 | This assumes your assembler supports local labels, as the GNU assembler | |
259 | and most Unix assemblers do. | |
260 | ||
261 | Speaking of labels, jumps from one `asm' to another are not | |
262 | supported. The compiler's optimizers do not know about these jumps, | |
263 | and therefore they cannot take account of them when deciding how to | |
264 | optimize. | |
265 | ||
266 | Usually the most convenient way to use these `asm' instructions is to | |
267 | encapsulate them in macros that look like functions. For example, | |
268 | ||
269 | #define sin(x) \ | |
270 | ({ double __value, __arg = (x); \ | |
271 | asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ | |
272 | __value; }) | |
273 | ||
274 | Here the variable `__arg' is used to make sure that the instruction | |
275 | operates on a proper `double' value, and to accept only those arguments | |
276 | `x' which can convert automatically to a `double'. | |
277 | ||
278 | Another way to make sure the instruction operates on the correct | |
279 | data type is to use a cast in the `asm'. This is different from using a | |
280 | variable `__arg' in that it converts more different types. For | |
281 | example, if the desired type were `int', casting the argument to `int' | |
282 | would accept a pointer with no complaint, while assigning the argument | |
283 | to an `int' variable named `__arg' would warn about using a pointer | |
284 | unless the caller explicitly casts it. | |
285 | ||
286 | If an `asm' has output operands, GNU CC assumes for optimization | |
287 | purposes that the instruction has no side effects except to change the | |
288 | output operands. This does not mean that instructions with a side | |
289 | effect cannot be used, but you must be careful, because the compiler | |
290 | may eliminate them if the output operands aren't used, or move them out | |
291 | of loops, or replace two with one if they constitute a common | |
292 | subexpression. Also, if your instruction does have a side effect on a | |
293 | variable that otherwise appears not to change, the old value of the | |
294 | variable may be reused later if it happens to be found in a register. | |
295 | ||
296 | You can prevent an `asm' instruction from being deleted, moved | |
297 | significantly, or combined, by writing the keyword `volatile' after the | |
298 | `asm'. For example: | |
299 | ||
300 | #define set_priority(x) \ | |
301 | asm volatile ("set_priority %0": /* no outputs */ : "g" (x)) | |
302 | ||
303 | An instruction without output operands will not be deleted or moved | |
304 | significantly, regardless, unless it is unreachable. | |
305 | ||
306 | Note that even a volatile `asm' instruction can be moved in ways | |
307 | that appear insignificant to the compiler, such as across jump | |
308 | instructions. You can't expect a sequence of volatile `asm' | |
309 | instructions to remain perfectly consecutive. If you want consecutive | |
310 | output, use a single `asm'. | |
311 | ||
312 | It is a natural idea to look for a way to give access to the | |
313 | condition code left by the assembler instruction. However, when we | |
314 | attempted to implement this, we found no way to make it work reliably. | |
315 | The problem is that output operands might need reloading, which would | |
316 | result in additional following "store" instructions. On most machines, | |
317 | these instructions would alter the condition code before there was time | |
318 | to test it. This problem doesn't arise for ordinary "test" and | |
319 | "compare" instructions because they don't have any output operands. | |
320 | ||
321 | If you are writing a header file that should be includable in ANSI C | |
322 | programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::. | |
323 | ||
324 | \1f | |
325 | File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: C Extensions | |
326 | ||
327 | Controlling Names Used in Assembler Code | |
328 | ======================================== | |
329 | ||
330 | You can specify the name to be used in the assembler code for a C | |
331 | function or variable by writing the `asm' (or `__asm__') keyword after | |
332 | the declarator as follows: | |
333 | ||
334 | int foo asm ("myfoo") = 2; | |
335 | ||
336 | This specifies that the name to be used for the variable `foo' in the | |
337 | assembler code should be `myfoo' rather than the usual `_foo'. | |
338 | ||
339 | On systems where an underscore is normally prepended to the name of | |
340 | a C function or variable, this feature allows you to define names for | |
341 | the linker that do not start with an underscore. | |
342 | ||
343 | You cannot use `asm' in this way in a function *definition*; but you | |
344 | can get the same effect by writing a declaration for the function | |
345 | before its definition and putting `asm' there, like this: | |
346 | ||
347 | extern func () asm ("FUNC"); | |
348 | ||
349 | func (x, y) | |
350 | int x, y; | |
351 | ... | |
352 | ||
353 | It is up to you to make sure that the assembler names you choose do | |
354 | not conflict with any other assembler symbols. Also, you must not use a | |
355 | register name; that would produce completely invalid assembler code. | |
356 | GNU CC does not as yet have the ability to store static variables in | |
357 | registers. Perhaps that will be added. | |
358 | ||
359 | \1f | |
360 | File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions | |
361 | ||
362 | Variables in Specified Registers | |
363 | ================================ | |
364 | ||
365 | GNU C allows you to put a few global variables into specified | |
366 | hardware registers. You can also specify the register in which an | |
367 | ordinary register variable should be allocated. | |
368 | ||
369 | * Global register variables reserve registers throughout the program. | |
370 | This may be useful in programs such as programming language | |
371 | interpreters which have a couple of global variables that are | |
372 | accessed very often. | |
373 | ||
374 | * Local register variables in specific registers do not reserve the | |
375 | registers. The compiler's data flow analysis is capable of | |
376 | determining where the specified registers contain live values, and | |
377 | where they are available for other uses. | |
378 | ||
379 | These local variables are sometimes convenient for use with the | |
380 | extended `asm' feature (*note Extended Asm::.), if you want to | |
381 | write one output of the assembler instruction directly into a | |
382 | particular register. (This will work provided the register you | |
383 | specify fits the constraints specified for that operand in the | |
384 | `asm'.) | |
385 | ||
386 | * Menu: | |
387 | ||
388 | * Global Reg Vars:: | |
389 | * Local Reg Vars:: | |
390 | ||
391 | \1f | |
392 | File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars | |
393 | ||
394 | Defining Global Register Variables | |
395 | ---------------------------------- | |
396 | ||
397 | You can define a global register variable in GNU C like this: | |
398 | ||
399 | register int *foo asm ("a5"); | |
400 | ||
401 | Here `a5' is the name of the register which should be used. Choose a | |
402 | register which is normally saved and restored by function calls on your | |
403 | machine, so that library routines will not clobber it. | |
404 | ||
405 | Naturally the register name is cpu-dependent, so you would need to | |
406 | conditionalize your program according to cpu type. The register `a5' | |
407 | would be a good choice on a 68000 for a variable of pointer type. On | |
408 | machines with register windows, be sure to choose a "global" register | |
409 | that is not affected magically by the function call mechanism. | |
410 | ||
411 | In addition, operating systems on one type of cpu may differ in how | |
412 | they name the registers; then you would need additional conditionals. | |
413 | For example, some 68000 operating systems call this register `%a5'. | |
414 | ||
415 | Eventually there may be a way of asking the compiler to choose a | |
416 | register automatically, but first we need to figure out how it should | |
417 | choose and how to enable you to guide the choice. No solution is | |
418 | evident. | |
419 | ||
420 | Defining a global register variable in a certain register reserves | |
421 | that register entirely for this use, at least within the current | |
422 | compilation. The register will not be allocated for any other purpose | |
423 | in the functions in the current compilation. The register will not be | |
424 | saved and restored by these functions. Stores into this register are | |
425 | never deleted even if they would appear to be dead, but references may | |
426 | be deleted or moved or simplified. | |
427 | ||
428 | It is not safe to access the global register variables from signal | |
429 | handlers, or from more than one thread of control, because the system | |
430 | library routines may temporarily use the register for other things | |
431 | (unless you recompile them specially for the task at hand). | |
432 | ||
433 | It is not safe for one function that uses a global register variable | |
434 | to call another such function `foo' by way of a third function `lose' | |
435 | that was compiled without knowledge of this variable (i.e. in a | |
436 | different source file in which the variable wasn't declared). This is | |
437 | because `lose' might save the register and put some other value there. | |
438 | For example, you can't expect a global register variable to be | |
439 | available in the comparison-function that you pass to `qsort', since | |
440 | `qsort' might have put something else in that register. (If you are | |
441 | prepared to recompile `qsort' with the same global register variable, | |
442 | you can solve this problem.) | |
443 | ||
444 | If you want to recompile `qsort' or other source files which do not | |
445 | actually use your global register variable, so that they will not use | |
446 | that register for any other purpose, then it suffices to specify the | |
447 | compiler option `-ffixed-REG'. You need not actually add a global | |
448 | register declaration to their source code. | |
449 | ||
450 | A function which can alter the value of a global register variable | |
451 | cannot safely be called from a function compiled without this variable, | |
452 | because it could clobber the value the caller expects to find there on | |
453 | return. Therefore, the function which is the entry point into the part | |
454 | of the program that uses the global register variable must explicitly | |
455 | save and restore the value which belongs to its caller. | |
456 | ||
457 | On most machines, `longjmp' will restore to each global register | |
458 | variable the value it had at the time of the `setjmp'. On some | |
459 | machines, however, `longjmp' will not change the value of global | |
460 | register variables. To be portable, the function that called `setjmp' | |
461 | should make other arrangements to save the values of the global register | |
462 | variables, and to restore them in a `longjmp'. This way, the same | |
463 | thing will happen regardless of what `longjmp' does. | |
464 | ||
465 | All global register variable declarations must precede all function | |
466 | definitions. If such a declaration could appear after function | |
467 | definitions, the declaration would be too late to prevent the register | |
468 | from being used for other purposes in the preceding functions. | |
469 | ||
470 | Global register variables may not have initial values, because an | |
471 | executable file has no means to supply initial contents for a register. | |
472 | ||
473 | On the Sparc, there are reports that g3 ... g7 are suitable | |
474 | registers, but certain library functions, such as `getwd', as well as | |
475 | the subroutines for division and remainder, modify g3 and g4. g1 and | |
476 | g2 are local temporaries. | |
477 | ||
478 | On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of | |
479 | course, it will not do to use more than a few of those. | |
480 | ||
481 | \1f | |
482 | File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars | |
483 | ||
484 | Specifying Registers for Local Variables | |
485 | ---------------------------------------- | |
486 | ||
487 | You can define a local register variable with a specified register | |
488 | like this: | |
489 | ||
490 | register int *foo asm ("a5"); | |
491 | ||
492 | Here `a5' is the name of the register which should be used. Note that | |
493 | this is the same syntax used for defining global register variables, | |
494 | but for a local variable it would appear within a function. | |
495 | ||
496 | Naturally the register name is cpu-dependent, but this is not a | |
497 | problem, since specific registers are most often useful with explicit | |
498 | assembler instructions (*note Extended Asm::.). Both of these things | |
499 | generally require that you conditionalize your program according to cpu | |
500 | type. | |
501 | ||
502 | In addition, operating systems on one type of cpu may differ in how | |
503 | they name the registers; then you would need additional conditionals. | |
504 | For example, some 68000 operating systems call this register `%a5'. | |
505 | ||
506 | Eventually there may be a way of asking the compiler to choose a | |
507 | register automatically, but first we need to figure out how it should | |
508 | choose and how to enable you to guide the choice. No solution is | |
509 | evident. | |
510 | ||
511 | Defining such a register variable does not reserve the register; it | |
512 | remains available for other uses in places where flow control determines | |
513 | the variable's value is not live. However, these registers are made | |
514 | unavailable for use in the reload pass. I would not be surprised if | |
515 | excessive use of this feature leaves the compiler too few available | |
516 | registers to compile certain functions. | |
517 | ||
518 | \1f | |
519 | File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions | |
520 | ||
521 | Alternate Keywords | |
522 | ================== | |
523 | ||
524 | The option `-traditional' disables certain keywords; `-ansi' | |
525 | disables certain others. This causes trouble when you want to use GNU C | |
526 | extensions, or ANSI C features, in a general-purpose header file that | |
527 | should be usable by all programs, including ANSI C programs and | |
528 | traditional ones. The keywords `asm', `typeof' and `inline' cannot be | |
529 | used since they won't work in a program compiled with `-ansi', while | |
530 | the keywords `const', `volatile', `signed', `typeof' and `inline' won't | |
531 | work in a program compiled with `-traditional'. | |
532 | ||
533 | The way to solve these problems is to put `__' at the beginning and | |
534 | end of each problematical keyword. For example, use `__asm__' instead | |
535 | of `asm', `__const__' instead of `const', and `__inline__' instead of | |
536 | `inline'. | |
537 | ||
538 | Other C compilers won't accept these alternative keywords; if you | |
539 | want to compile with another compiler, you can define the alternate | |
540 | keywords as macros to replace them with the customary keywords. It | |
541 | looks like this: | |
542 | ||
543 | #ifndef __GNUC__ | |
544 | #define __asm__ asm | |
545 | #endif | |
546 | ||
547 | `-pedantic' causes warnings for many GNU C extensions. You can | |
548 | prevent such warnings within one expression by writing `__extension__' | |
549 | before the expression. `__extension__' has no effect aside from this. | |
550 | ||
551 | \1f | |
552 | File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions | |
553 | ||
554 | Incomplete `enum' Types | |
555 | ======================= | |
556 | ||
557 | You can define an `enum' tag without specifying its possible values. | |
558 | This results in an incomplete type, much like what you get if you write | |
559 | `struct foo' without describing the elements. A later declaration | |
560 | which does specify the possible values completes the type. | |
561 | ||
562 | You can't allocate variables or storage using the type while it is | |
563 | incomplete. However, you can work with pointers to that type. | |
564 | ||
565 | This extension may not be very useful, but it makes the handling of | |
566 | `enum' more consistent with the way `struct' and `union' are handled. | |
567 | ||
568 | This extension is not supported by GNU C++. | |
569 | ||
570 | \1f | |
571 | File: gcc.info, Node: Function Names, Next: Return Address, Prev: Incomplete Enums, Up: C Extensions | |
572 | ||
573 | Function Names as Strings | |
574 | ========================= | |
575 | ||
576 | GNU CC predefines two string variables to be the name of the current | |
577 | function. The variable `__FUNCTION__' is the name of the function as | |
578 | it appears in the source. The variable `__PRETTY_FUNCTION__' is the | |
579 | name of the function pretty printed in a language specific fashion. | |
580 | ||
581 | These names are always the same in a C function, but in a C++ | |
582 | function they may be different. For example, this program: | |
583 | ||
584 | extern "C" { | |
585 | extern int printf (char *, ...); | |
586 | } | |
587 | ||
588 | class a { | |
589 | public: | |
590 | sub (int i) | |
591 | { | |
592 | printf ("__FUNCTION__ = %s\n", __FUNCTION__); | |
593 | printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__); | |
594 | } | |
595 | }; | |
596 | ||
597 | int | |
598 | main (void) | |
599 | { | |
600 | a ax; | |
601 | ax.sub (0); | |
602 | return 0; | |
603 | } | |
604 | ||
605 | gives this output: | |
606 | ||
607 | __FUNCTION__ = sub | |
608 | __PRETTY_FUNCTION__ = int a::sub (int) | |
609 | ||
610 | These names are not macros: they are predefined string variables. | |
611 | For example, `#ifdef __FUNCTION__' does not have any special meaning | |
612 | inside a function, since the preprocessor does not do anything special | |
613 | with the identifier `__FUNCTION__'. | |
614 | ||
615 | \1f | |
616 | File: gcc.info, Node: Return Address, Prev: Function Names, Up: C Extensions | |
617 | ||
618 | Getting the Return or Frame Address of a Function | |
619 | ================================================= | |
620 | ||
621 | These functions may be used to get information about the callers of a | |
622 | function. | |
623 | ||
624 | `__builtin_return_address (LEVEL)' | |
625 | This function returns the return address of the current function, | |
626 | or of one of its callers. The LEVEL argument is number of frames | |
627 | to scan up the call stack. A value of `0' yields the return | |
628 | address of the current function, a value of `1' yields the return | |
629 | address of the caller of the current function, and so forth. | |
630 | ||
631 | The LEVEL argument must be a constant integer. | |
632 | ||
633 | On some machines it may be impossible to determine the return | |
634 | address of any function other than the current one; in such cases, | |
635 | or when the top of the stack has been reached, this function will | |
636 | return `0'. | |
637 | ||
638 | This function should only be used with a non-zero argument for | |
639 | debugging purposes. | |
640 | ||
641 | `__builtin_frame_address (LEVEL)' | |
642 | This function is similar to `__builtin_return_address', but it | |
643 | returns the address of the function frame rather than the return | |
644 | address of the function. Calling `__builtin_frame_address' with a | |
645 | value of `0' yields the frame address of the current function, a | |
646 | value of `1' yields the frame address of the caller of the current | |
647 | function, and so forth. | |
648 | ||
649 | The frame is the area on the stack which holds local variables and | |
650 | saved registers. The frame address is normally the address of the | |
651 | first word pushed on to the stack by the function. However, the | |
652 | exact definition depends upon the processor and the calling | |
653 | convention. If the processor has a dedicated frame pointer | |
654 | register, and the function has a frame, then | |
655 | `__builtin_frame_address' will return the value of the frame | |
656 | pointer register. | |
657 | ||
658 | The caveats that apply to `__builtin_return_address' apply to this | |
659 | function as well. | |
660 | ||
661 | \1f | |
662 | File: gcc.info, Node: C++ Extensions, Next: Gcov, Prev: C Extensions, Up: Top | |
663 | ||
664 | Extensions to the C++ Language | |
665 | ****************************** | |
666 | ||
667 | The GNU compiler provides these extensions to the C++ language (and | |
668 | you can also use most of the C language extensions in your C++ | |
669 | programs). If you want to write code that checks whether these | |
670 | features are available, you can test for the GNU compiler the same way | |
671 | as for C programs: check for a predefined macro `__GNUC__'. You can | |
672 | also use `__GNUG__' to test specifically for GNU C++ (*note Standard | |
673 | Predefined Macros: (cpp.info)Standard Predefined.). | |
674 | ||
675 | * Menu: | |
676 | ||
677 | * Naming Results:: Giving a name to C++ function return values. | |
678 | * Min and Max:: C++ Minimum and maximum operators. | |
679 | * Destructors and Goto:: Goto is safe to use in C++ even when destructors | |
680 | are needed. | |
681 | * C++ Interface:: You can use a single C++ header file for both | |
682 | declarations and definitions. | |
683 | * Template Instantiation:: Methods for ensuring that exactly one copy of | |
684 | each needed template instantiation is emitted. | |
685 | * C++ Signatures:: You can specify abstract types to get subtype | |
686 | polymorphism independent from inheritance. | |
687 | ||
688 | \1f | |
689 | File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions | |
690 | ||
691 | Named Return Values in C++ | |
692 | ========================== | |
693 | ||
694 | GNU C++ extends the function-definition syntax to allow you to | |
695 | specify a name for the result of a function outside the body of the | |
696 | definition, in C++ programs: | |
697 | ||
698 | TYPE | |
699 | FUNCTIONNAME (ARGS) return RESULTNAME; | |
700 | { | |
701 | ... | |
702 | BODY | |
703 | ... | |
704 | } | |
705 | ||
706 | You can use this feature to avoid an extra constructor call when a | |
707 | function result has a class type. For example, consider a function | |
708 | `m', declared as `X v = m ();', whose result is of class `X': | |
709 | ||
710 | X | |
711 | m () | |
712 | { | |
713 | X b; | |
714 | b.a = 23; | |
715 | return b; | |
716 | } | |
717 | ||
718 | Although `m' appears to have no arguments, in fact it has one | |
719 | implicit argument: the address of the return value. At invocation, the | |
720 | address of enough space to hold `v' is sent in as the implicit argument. | |
721 | Then `b' is constructed and its `a' field is set to the value 23. | |
722 | Finally, a copy constructor (a constructor of the form `X(X&)') is | |
723 | applied to `b', with the (implicit) return value location as the | |
724 | target, so that `v' is now bound to the return value. | |
725 | ||
726 | But this is wasteful. The local `b' is declared just to hold | |
727 | something that will be copied right out. While a compiler that | |
728 | combined an "elision" algorithm with interprocedural data flow analysis | |
729 | could conceivably eliminate all of this, it is much more practical to | |
730 | allow you to assist the compiler in generating efficient code by | |
731 | manipulating the return value explicitly, thus avoiding the local | |
732 | variable and copy constructor altogether. | |
733 | ||
734 | Using the extended GNU C++ function-definition syntax, you can avoid | |
735 | the temporary allocation and copying by naming `r' as your return value | |
736 | at the outset, and assigning to its `a' field directly: | |
737 | ||
738 | X | |
739 | m () return r; | |
740 | { | |
741 | r.a = 23; | |
742 | } | |
743 | ||
744 | The declaration of `r' is a standard, proper declaration, whose effects | |
745 | are executed *before* any of the body of `m'. | |
746 | ||
747 | Functions of this type impose no additional restrictions; in | |
748 | particular, you can execute `return' statements, or return implicitly by | |
749 | reaching the end of the function body ("falling off the edge"). Cases | |
750 | like | |
751 | ||
752 | X | |
753 | m () return r (23); | |
754 | { | |
755 | return; | |
756 | } | |
757 | ||
758 | (or even `X m () return r (23); { }') are unambiguous, since the return | |
759 | value `r' has been initialized in either case. The following code may | |
760 | be hard to read, but also works predictably: | |
761 | ||
762 | X | |
763 | m () return r; | |
764 | { | |
765 | X b; | |
766 | return b; | |
767 | } | |
768 | ||
769 | The return value slot denoted by `r' is initialized at the outset, | |
770 | but the statement `return b;' overrides this value. The compiler deals | |
771 | with this by destroying `r' (calling the destructor if there is one, or | |
772 | doing nothing if there is not), and then reinitializing `r' with `b'. | |
773 | ||
774 | This extension is provided primarily to help people who use | |
775 | overloaded operators, where there is a great need to control not just | |
776 | the arguments, but the return values of functions. For classes where | |
777 | the copy constructor incurs a heavy performance penalty (especially in | |
778 | the common case where there is a quick default constructor), this is a | |
779 | major savings. The disadvantage of this extension is that you do not | |
780 | control when the default constructor for the return value is called: it | |
781 | is always called at the beginning. | |
782 | ||
783 | \1f | |
784 | File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions | |
785 | ||
786 | Minimum and Maximum Operators in C++ | |
787 | ==================================== | |
788 | ||
789 | It is very convenient to have operators which return the "minimum" | |
790 | or the "maximum" of two arguments. In GNU C++ (but not in GNU C), | |
791 | ||
792 | `A <? B' | |
793 | is the "minimum", returning the smaller of the numeric values A | |
794 | and B; | |
795 | ||
796 | `A >? B' | |
797 | is the "maximum", returning the larger of the numeric values A and | |
798 | B. | |
799 | ||
800 | These operations are not primitive in ordinary C++, since you can | |
801 | use a macro to return the minimum of two things in C++, as in the | |
802 | following example. | |
803 | ||
804 | #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y)) | |
805 | ||
806 | You might then use `int min = MIN (i, j);' to set MIN to the minimum | |
807 | value of variables I and J. | |
808 | ||
809 | However, side effects in `X' or `Y' may cause unintended behavior. | |
810 | For example, `MIN (i++, j++)' will fail, incrementing the smaller | |
811 | counter twice. A GNU C extension allows you to write safe macros that | |
812 | avoid this kind of problem (*note Naming an Expression's Type: Naming | |
813 | Types.). However, writing `MIN' and `MAX' as macros also forces you to | |
814 | use function-call notation for a fundamental arithmetic operation. | |
815 | Using GNU C++ extensions, you can write `int min = i <? j;' instead. | |
816 | ||
817 | Since `<?' and `>?' are built into the compiler, they properly | |
818 | handle expressions with side-effects; `int min = i++ <? j++;' works | |
819 | correctly. | |
820 | ||
821 | \1f | |
822 | File: gcc.info, Node: Destructors and Goto, Next: C++ Interface, Prev: Min and Max, Up: C++ Extensions | |
823 | ||
824 | `goto' and Destructors in GNU C++ | |
825 | ================================= | |
826 | ||
827 | In C++ programs, you can safely use the `goto' statement. When you | |
828 | use it to exit a block which contains aggregates requiring destructors, | |
829 | the destructors will run before the `goto' transfers control. | |
830 | ||
831 | The compiler still forbids using `goto' to *enter* a scope that | |
832 | requires constructors. | |
833 | ||
834 | \1f | |
835 | File: gcc.info, Node: C++ Interface, Next: Template Instantiation, Prev: Destructors and Goto, Up: C++ Extensions | |
836 | ||
837 | Declarations and Definitions in One Header | |
838 | ========================================== | |
839 | ||
840 | C++ object definitions can be quite complex. In principle, your | |
841 | source code will need two kinds of things for each object that you use | |
842 | across more than one source file. First, you need an "interface" | |
843 | specification, describing its structure with type declarations and | |
844 | function prototypes. Second, you need the "implementation" itself. It | |
845 | can be tedious to maintain a separate interface description in a header | |
846 | file, in parallel to the actual implementation. It is also dangerous, | |
847 | since separate interface and implementation definitions may not remain | |
848 | parallel. | |
849 | ||
850 | With GNU C++, you can use a single header file for both purposes. | |
851 | ||
852 | *Warning:* The mechanism to specify this is in transition. For the | |
853 | nonce, you must use one of two `#pragma' commands; in a future | |
854 | release of GNU C++, an alternative mechanism will make these | |
855 | `#pragma' commands unnecessary. | |
856 | ||
857 | The header file contains the full definitions, but is marked with | |
858 | `#pragma interface' in the source code. This allows the compiler to | |
859 | use the header file only as an interface specification when ordinary | |
860 | source files incorporate it with `#include'. In the single source file | |
861 | where the full implementation belongs, you can use either a naming | |
862 | convention or `#pragma implementation' to indicate this alternate use | |
863 | of the header file. | |
864 | ||
865 | `#pragma interface' | |
866 | `#pragma interface "SUBDIR/OBJECTS.h"' | |
867 | Use this directive in *header files* that define object classes, | |
868 | to save space in most of the object files that use those classes. | |
869 | Normally, local copies of certain information (backup copies of | |
870 | inline member functions, debugging information, and the internal | |
871 | tables that implement virtual functions) must be kept in each | |
872 | object file that includes class definitions. You can use this | |
873 | pragma to avoid such duplication. When a header file containing | |
874 | `#pragma interface' is included in a compilation, this auxiliary | |
875 | information will not be generated (unless the main input source | |
876 | file itself uses `#pragma implementation'). Instead, the object | |
877 | files will contain references to be resolved at link time. | |
878 | ||
879 | The second form of this directive is useful for the case where you | |
880 | have multiple headers with the same name in different directories. | |
881 | If you use this form, you must specify the same string to `#pragma | |
882 | implementation'. | |
883 | ||
884 | `#pragma implementation' | |
885 | `#pragma implementation "OBJECTS.h"' | |
886 | Use this pragma in a *main input file*, when you want full output | |
887 | from included header files to be generated (and made globally | |
888 | visible). The included header file, in turn, should use `#pragma | |
889 | interface'. Backup copies of inline member functions, debugging | |
890 | information, and the internal tables used to implement virtual | |
891 | functions are all generated in implementation files. | |
892 | ||
893 | If you use `#pragma implementation' with no argument, it applies to | |
894 | an include file with the same basename(1) as your source file. | |
895 | For example, in `allclass.cc', giving just `#pragma implementation' | |
896 | by itself is equivalent to `#pragma implementation "allclass.h"'. | |
897 | ||
898 | In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as | |
899 | an implementation file whenever you would include it from | |
900 | `allclass.cc' even if you never specified `#pragma | |
901 | implementation'. This was deemed to be more trouble than it was | |
902 | worth, however, and disabled. | |
903 | ||
904 | If you use an explicit `#pragma implementation', it must appear in | |
905 | your source file *before* you include the affected header files. | |
906 | ||
907 | Use the string argument if you want a single implementation file to | |
908 | include code from multiple header files. (You must also use | |
909 | `#include' to include the header file; `#pragma implementation' | |
910 | only specifies how to use the file--it doesn't actually include | |
911 | it.) | |
912 | ||
913 | There is no way to split up the contents of a single header file | |
914 | into multiple implementation files. | |
915 | ||
916 | `#pragma implementation' and `#pragma interface' also have an effect | |
917 | on function inlining. | |
918 | ||
919 | If you define a class in a header file marked with `#pragma | |
920 | interface', the effect on a function defined in that class is similar to | |
921 | an explicit `extern' declaration--the compiler emits no code at all to | |
922 | define an independent version of the function. Its definition is used | |
923 | only for inlining with its callers. | |
924 | ||
925 | Conversely, when you include the same header file in a main source | |
926 | file that declares it as `#pragma implementation', the compiler emits | |
927 | code for the function itself; this defines a version of the function | |
928 | that can be found via pointers (or by callers compiled without | |
929 | inlining). If all calls to the function can be inlined, you can avoid | |
930 | emitting the function by compiling with `-fno-implement-inlines'. If | |
931 | any calls were not inlined, you will get linker errors. | |
932 | ||
933 | ---------- Footnotes ---------- | |
934 | ||
935 | (1) A file's "basename" was the name stripped of all leading path | |
936 | information and of trailing suffixes, such as `.h' or `.C' or `.cc'. | |
937 | ||
938 | \1f | |
939 | File: gcc.info, Node: Template Instantiation, Next: C++ Signatures, Prev: C++ Interface, Up: C++ Extensions | |
940 | ||
941 | Where's the Template? | |
942 | ===================== | |
943 | ||
944 | C++ templates are the first language feature to require more | |
945 | intelligence from the environment than one usually finds on a UNIX | |
946 | system. Somehow the compiler and linker have to make sure that each | |
947 | template instance occurs exactly once in the executable if it is needed, | |
948 | and not at all otherwise. There are two basic approaches to this | |
949 | problem, which I will refer to as the Borland model and the Cfront | |
950 | model. | |
951 | ||
952 | Borland model | |
953 | Borland C++ solved the template instantiation problem by adding | |
954 | the code equivalent of common blocks to their linker; the compiler | |
955 | emits template instances in each translation unit that uses them, | |
956 | and the linker collapses them together. The advantage of this | |
957 | model is that the linker only has to consider the object files | |
958 | themselves; there is no external complexity to worry about. This | |
959 | disadvantage is that compilation time is increased because the | |
960 | template code is being compiled repeatedly. Code written for this | |
961 | model tends to include definitions of all templates in the header | |
962 | file, since they must be seen to be instantiated. | |
963 | ||
964 | Cfront model | |
965 | The AT&T C++ translator, Cfront, solved the template instantiation | |
966 | problem by creating the notion of a template repository, an | |
967 | automatically maintained place where template instances are | |
968 | stored. A more modern version of the repository works as follows: | |
969 | As individual object files are built, the compiler places any | |
970 | template definitions and instantiations encountered in the | |
971 | repository. At link time, the link wrapper adds in the objects in | |
972 | the repository and compiles any needed instances that were not | |
973 | previously emitted. The advantages of this model are more optimal | |
974 | compilation speed and the ability to use the system linker; to | |
975 | implement the Borland model a compiler vendor also needs to | |
976 | replace the linker. The disadvantages are vastly increased | |
977 | complexity, and thus potential for error; for some code this can be | |
978 | just as transparent, but in practice it can been very difficult to | |
979 | build multiple programs in one directory and one program in | |
980 | multiple directories. Code written for this model tends to | |
981 | separate definitions of non-inline member templates into a | |
982 | separate file, which should be compiled separately. | |
983 | ||
984 | When used with GNU ld version 2.8 or later on an ELF system such as | |
985 | Linux/GNU or Solaris 2, or on Microsoft Windows, g++ supports the | |
986 | Borland model. On other systems, g++ implements neither automatic | |
987 | model. | |
988 | ||
989 | A future version of g++ will support a hybrid model whereby the | |
990 | compiler will emit any instantiations for which the template definition | |
991 | is included in the compile, and store template definitions and | |
992 | instantiation context information into the object file for the rest. | |
993 | The link wrapper will extract that information as necessary and invoke | |
994 | the compiler to produce the remaining instantiations. The linker will | |
995 | then combine duplicate instantiations. | |
996 | ||
997 | In the mean time, you have the following options for dealing with | |
998 | template instantiations: | |
999 | ||
1000 | 1. Compile your code with `-fno-implicit-templates' to disable the | |
1001 | implicit generation of template instances, and explicitly | |
1002 | instantiate all the ones you use. This approach requires more | |
1003 | knowledge of exactly which instances you need than do the others, | |
1004 | but it's less mysterious and allows greater control. You can | |
1005 | scatter the explicit instantiations throughout your program, | |
1006 | perhaps putting them in the translation units where the instances | |
1007 | are used or the translation units that define the templates | |
1008 | themselves; you can put all of the explicit instantiations you | |
1009 | need into one big file; or you can create small files like | |
1010 | ||
1011 | #include "Foo.h" | |
1012 | #include "Foo.cc" | |
1013 | ||
1014 | template class Foo<int>; | |
1015 | template ostream& operator << | |
1016 | (ostream&, const Foo<int>&); | |
1017 | ||
1018 | for each of the instances you need, and create a template | |
1019 | instantiation library from those. | |
1020 | ||
1021 | If you are using Cfront-model code, you can probably get away with | |
1022 | not using `-fno-implicit-templates' when compiling files that don't | |
1023 | `#include' the member template definitions. | |
1024 | ||
1025 | If you use one big file to do the instantiations, you may want to | |
1026 | compile it without `-fno-implicit-templates' so you get all of the | |
1027 | instances required by your explicit instantiations (but not by any | |
1028 | other files) without having to specify them as well. | |
1029 | ||
1030 | g++ has extended the template instantiation syntax outlined in the | |
1031 | Working Paper to allow forward declaration of explicit | |
1032 | instantiations, explicit instantiation of members of template | |
1033 | classes and instantiation of the compiler support data for a | |
1034 | template class (i.e. the vtable) without instantiating any of its | |
1035 | members: | |
1036 | ||
1037 | extern template int max (int, int); | |
1038 | template void Foo<int>::f (); | |
1039 | inline template class Foo<int>; | |
1040 | ||
1041 | 2. Do nothing. Pretend g++ does implement automatic instantiation | |
1042 | management. Code written for the Borland model will work fine, but | |
1043 | each translation unit will contain instances of each of the | |
1044 | templates it uses. In a large program, this can lead to an | |
1045 | unacceptable amount of code duplication. | |
1046 | ||
1047 | 3. Add `#pragma interface' to all files containing template | |
1048 | definitions. For each of these files, add `#pragma implementation | |
1049 | "FILENAME"' to the top of some `.C' file which `#include's it. | |
1050 | Then compile everything with `-fexternal-templates'. The | |
1051 | templates will then only be expanded in the translation unit which | |
1052 | implements them (i.e. has a `#pragma implementation' line for the | |
1053 | file where they live); all other files will use external | |
1054 | references. If you're lucky, everything should work properly. If | |
1055 | you get undefined symbol errors, you need to make sure that each | |
1056 | template instance which is used in the program is used in the file | |
1057 | which implements that template. If you don't have any use for a | |
1058 | particular instance in that file, you can just instantiate it | |
1059 | explicitly, using the syntax from the latest C++ working paper: | |
1060 | ||
1061 | template class A<int>; | |
1062 | template ostream& operator << (ostream&, const A<int>&); | |
1063 | ||
1064 | This strategy will work with code written for either model. If | |
1065 | you are using code written for the Cfront model, the file | |
1066 | containing a class template and the file containing its member | |
1067 | templates should be implemented in the same translation unit. | |
1068 | ||
1069 | A slight variation on this approach is to instead use the flag | |
1070 | `-falt-external-templates'; this flag causes template instances to | |
1071 | be emitted in the translation unit that implements the header | |
1072 | where they are first instantiated, rather than the one which | |
1073 | implements the file where the templates are defined. This header | |
1074 | must be the same in all translation units, or things are likely to | |
1075 | break. | |
1076 | ||
1077 | *Note Declarations and Definitions in One Header: C++ Interface, | |
1078 | for more discussion of these pragmas. | |
1079 |