Yes, Actually the net result is the productivity bump for the devs I pay. Before that the trend was to take a small break. Now, they are focused because the compilation of the whole code is almost instant. I am a business man before being a dev. Every dollar paid must be productive. I don't regret my move but it was painful to do. Le ven. 17 févr. 2023 à 12:39, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> a écrit : > > > On Fri, 17 Feb 2023, 07:24 Julien D Arques via Gcc-help, < > gcc-help@xxxxxxxxxxx> wrote: > >> Hi, >> I just finished a project that required to generate a static library out >> of >> heavily templated code. >> > > Why? > > >> It has been a productivity nightmare and will be hard to extend if needs >> be. >> Many "extern template XXX" in .hpp and corresponding "template XXX" in >> .cpp >> that killed my day (many possible type combinations). >> > > But why did you do that? > > >> That need may happen again in a future project and I really don't want to >> reiterate what I did. >> >> Maybe modules will help but I need a solution that can be applied now. >> >> Do we have a hack in GCC to avoid this pitfall? >> > > Just don't do it. > > Templates are implicitly instantiated as needed. Why do you need them > defined in the static library, instead of letting users instantiate them as > needed when compiling the headers? > > If you're doing it to make compiling those headers faster, that's a valid > choice you've made, but you're trading more work for you when creating the > library vs less work for the compiler when using the library. If you choose > to do that, then I'm afraid there's no short cut to avoid doing the extra > work. > > One alternative would be to define the entry points to the library API as > non-template functions, and then just let the templates be implicitly > instantiated for the definitions of those functions in the library. But > that would mean designing a different API and that might be just as much > work (if it's even practical to do that). >
