The compiler is the canonical example of a metaprogram: it translates a program written in one language (such as C) into an equivalent program written in another language (object code).
Of course, when we invoke a compiler we are not metaprogramming, we are simply using a metaprogram, but it is important to be aware of what's going on. We may prefer to program in higher-level languages but we should remember the compiler's role as our translator.
We lean on compilers: we rely on them to faithfully convert our source code into an executable; we expect different compilers to produce "the same" results on different platforms; and we want them to do all this while tracking language changes.
In some environments these considerations are taken very seriously. For safety critical software, a compiler will be tested systematically to confirm the object code output by various test cases is correct. In such places, you cannot simply apply the latest patch or tweak optimisation flags. You may even prefer to work in C rather than C++ since C is a smaller language which translates more directly to object code.
In other environments we train ourselves to get along with our compilers. We accept limitations, report defects, find workarounds, upgrade and apply patches. Optimisation settings are fine-tuned. We prefer tried-and-tested and, above all, supported brands. We monitor newsgroups and share our experiences.
One last point before leaving compilers: C and C++ provide a hook which
allows you to embed assembler code in a source file – that's what the asm
keyword is for. I guess this too is metaprogramming in a rather back-to-front
form. The asm keyword instructs the compiler to suspend its normal operation
and include your handwritten assembler code directly. Its exact operation is
implementation dependent, and, fortunately, rarely needed.
| Copyright © 2005 Thomas Guest |