On Fri, Jan 29, 2010 at 06:23:45PM -0800, Michael Witten wrote: > On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini <paolo.carl...@oracle.com> > wrote: > > Even for implementors knowing *very* well both the details of the C++ > > standard and the internals of a specific front-end, implementing export > > is an *highly* non-trivial task. > > However, I have a gut feeling that at least a restricted version of > 'export' (or a cousin of 'export') could be both useful and trivial to > implement: Perhaps a limited form could simply automate the > not-infrequently employed practice of creating a translation unit > specifically for explicit template instantiations.
The typical implementations have all sorts of problems: where do you store these extra explicit template expansions? If you make a database for the template expansions, you have locking problem, or experience frequent corruption or the like; I've had such problems making such systems work that we've generally resorted to turning it off (e.g. tell Sun's compiler to expand templates into static functions). These problems might be overcome, but it hasn't been done because it is a hard problem. The main difficulty is building a robust flow that supports parallel builds and an efficient link pass.