Re: Tip to reduce manual template declaration?

[Julien D Arques <acc.gccquestions@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

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@gmail.com> a
écrit :

>
>
> On Fri, 17 Feb 2023, 07:24 Julien D Arques via Gcc-help, <
> gcc-help@gcc.gnu.org> 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).
>