3

My first thought was that this term doesn't require a formal definition in the standard, as it can be inferred just by using the English language, that is, a translated translation unit is just the object file produced by the compiler from its correspondent translation unit. But I'm not sure if this is the correct interpretation given the the text in [lex.phases]/1.8, as shown below:

[lex.phases]/1.8:

Translated translation units and instantiation units are combined as follows: [ Note: Some or all of these may be supplied from a library. — end note ] Each translated translation unit is examined to produce a list of required instantiations. [ Note: This may include instantiations which have been explicitly requested (14.7.2). — end note ] The definitions of the required templates are located. It is implementation-defined whether the source of the translation units containing these definitions is required to be available. [ Note: An implementation could encode sufficient information into the translated translation unit so as to ensure the source is not required here. — end note ] All the required instantiations are performed to produce instantiation units. [ Note: These are similar to translated translation units, but contain no references to uninstantiated templates and no template definitions. —end note ] The program is ill-formed if any instantiation fails.

Alexander
  • 2,581
  • 11
  • 17
  • Well, phase 7 says "The resulting tokens are syntactically and semantically analyzed and **translated as a translation unit.**" (emphasis mine). "Translated translation unit" is then the outcome of this process. As far as I can tell, the authors have something like an internal abstract-syntax-tree representation in mind; not neccesarily something that's physically written to disk as a file in some well-known format. Recall also that the compiler only has to work as-if the translation occurs in these phases - it doesn't have to implement them literally. – Igor Tandetnik May 13 '17 at 19:20
  • @IgorTandetnik I am almost convinced that my first thought was correct. Look at [this answer](http://stackoverflow.com/a/3045652/5479741) in SO: "Imports - which symbols the compiled code references (gets fixed up by linker)", i.e, the list of required instantiations (mentioned above in [lex.phases]/1.8) can be obtained from the symbols imported by the object file. It's also worth noting that the Standard doesn't mention the term "object file". So, it seems reasonable to think that a "translated translation unit" is the term used by the standard to mean an object file. Does that make sense? – Alexander May 13 '17 at 19:51
  • Object file formats currently in common use do not contain sufficient information to stamp out new template instantiations on demand; nor is a typical linker smart enough to pull that off. The common approach is for a compiler to embed into each object file every template instantiation used by something else in that file; and for the linker to discard all but one identical copies of each section of machine code found in those object files. In other words, linkers implement phase 9, not phase 8 or earlier. – Igor Tandetnik May 13 '17 at 19:59
  • It is theoretically possible for a compiler to write some kind of internal representation of a translation unit out to the file, with all semantical information intact; and then for a smart linker to combine these files and generate template instantiations on the fly. I'm not aware of any system that actually works this way. Once upon a time the standard defined a concept of exported templates, which pretty much required such an approach; it was later removed, essentially because compiler authors deemed the implementation infeasible, or at least prohibitively difficult. – Igor Tandetnik May 13 '17 at 20:04
  • In case you are curious, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf – Igor Tandetnik May 13 '17 at 20:10
  • Thanks for your replies and the link. I found [this answer in SO](http://stackoverflow.com/a/31743548/1042389) which seems to answer what I'm looking for. Specifically:`A translated translation unit (try to say that three times fast) is the output from compilation without templates instantiated. An instantiation unit is essentially the translated translation unit with templates instantiated.` – Alexander May 13 '17 at 22:35
  • @IgorTandetnik: Even when `export` was implemented, that's not how it apparently worked. Rather, the compiler basically embedded a reference to the source file into the object file. Then at link time, if the linker found that a template had been instantiated over a type that the object file didn't contain code for, the linker re-invoked the compiler to compile the source for the required type, and add it to the object file. Then control went back to the linker to continue its job. In this case "apparently" is based on use of Comeau C++, the one compiler that implemented `export`. – Jerry Coffin Mar 23 '23 at 03:22

0 Answers0