public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Julien D Arques <acc.gccquestions@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Tip to reduce manual template declaration?
Date: Fri, 17 Feb 2023 11:38:51 +0000	[thread overview]
Message-ID: <CAH6eHdSs0LpjwQCphRB_UEMpK+HHdAAiVz5kYoR126JizoMmKw@mail.gmail.com> (raw)
In-Reply-To: <CACS5Re-DO81QSqQF3GTJqjMELQ3GOF2yKcrBYKxwVGD2w6JKgw@mail.gmail.com>

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

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).

  reply	other threads:[~2023-02-17 11:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  7:23 Julien D Arques
2023-02-17 11:38 ` Jonathan Wakely [this message]
2023-02-17 12:02   ` Julien D Arques

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH6eHdSs0LpjwQCphRB_UEMpK+HHdAAiVz5kYoR126JizoMmKw@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=acc.gccquestions@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).