On Mon, Jan 16, 2012 at 12:32:01PM -0800, Adam Wilson wrote: > On Mon, 16 Jan 2012 12:08:53 -0800, H. S. Teoh > <hst...@quickfur.ath.cx> wrote: [...] > >One way to implement this is to store template/inline function bodies > >inside the precompiled object files as extra info that the compiler > >loads in order to be able to expand templates/inline functions, > >compute the size of structs/classes (because private members are not > >listed in the API file), and so on. How this is feasible to > >implement, I can't say; some platforms may not allow arbitrary data > >inside object files, so the compiler may not be able to store the > >requisite information in them. [...] > Not a bad idea, it's similar in function to .NET's Metadata. > unfortunately to be useful, other linkers would have to be taught how > to read that data... [...]
That depends on how you do it. If we assume, for argument's sake, that we are allowed to store arbitrary data inside an object file (say inside a debug section or something), then the compiler could for example store things like parsed function bodies, partial syntax trees, etc., that allows it to treat templates and inline functions as though they actually were embedded in the interface file. When asked to compile a source file that imports the library, the compiler would read the object file, extract this info and use it to do whatever it needs to do (expand templates, inline functions, emit non-inlined function bodies, etc.). The generated object file can then be linked by the system's usual linker, assuming that the extra info in the library's object file is marked such that the linker simply ignores it. The linker doesn't have to know anything about it because the compiler has already done whatever needs to be done with it when it compiled the source file that imported the library. In fact, if a particular platform doesn't support such extra data inside object files, the compiler can simply save the data in its own internal format in another file, and the library writer just ships this file along with the human-readable API file and any precompiled library object files. As long as the customer's compiler knows to look for this file when compiling source that imports the library, it will have enough info to do what it needs to do. T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
