0

Looking through the list of suggested "Similar questions", it seemed those would rather like header-only stuff, and one question which does want to separate but has different problems.

I have a folder with subfolders of utility classes, a lot of them templates. They were created as part of a previous project, but clearly separate, keeping in the back of the head: "might want to reuse later".

So now I am about to make this a static library to be used by other projects. Linked it to another project, included the headers, tried to use a class template, and boom: The linker complains. Right. What was I thinking. Those class templates have separate .cpp files for the bulk of the implementation - which hardly can get baked into a library binary if no template arguments are known at this stage, and the using project only knows the headers with the declarations. The separation had good reasons, though. The implementation includes a bunch of other headers deeper down to the system, which I do not want to bother the user of the library with.

So I wonder: In current versions of C++, can you actually, in some "elegant" way, somehow make a static library, which uses class templates, while not having the user be bothered with getting lots of extra stuff included by including library headers? Of course the fact of unknown template arguments does not change. But perhaps this has been addressed in ways I'm unaware of.

I'd like to avoid the "just put it all into the header and be done" way, if possible. (concrete template parameterization for a few in-advance-known parameters as suggested in one SO post is also not workable, this needs to be generic)

There is some vague idea in the back of my head now that I could try to refactor things in a way that would make only those parts templated that really need to, and still hiding some of the nasty details from the library user. This smells like extra abstraction acrobatics, though. Although I would also welcome suggestions in this direction, if there are tried & proven recipies to do such a transform.

I have had some surprizes with current C++, so before I go that route, perhaps someone knows about one of those that might help in this case?

sktpin
  • 317
  • 2
  • 15
  • 1
    The most relevant related question seems to be [Why can templates only be implemented in the header file?](https://stackoverflow.com/questions/495021/why-can-templates-only-be-implemented-in-the-header-file?rq=1) which pretty much explains why it won't work. – Some programmer dude Jun 16 '20 at 11:39
  • Perhaps what you're looking for is the [PImpl idiom](https://en.cppreference.com/w/cpp/language/pimpl) to hide *some* of the implementation details? Or explicit instantiation of your templates (see e.g. [Explicit template instantiation - when is it used?](https://stackoverflow.com/questions/2351148/explicit-template-instantiation-when-is-it-used))? – Some programmer dude Jun 16 '20 at 11:40
  • If available types are (small) known, you can only have code in cpp with their explicit instantiation in cpp – Jarod42 Jun 16 '20 at 11:40
  • There are no other way, it is mentionned in Stroustrup books. When a template project get big, there are no other path than implementing high level abstraction through polymorphism. And that is a good thing because it decreases compilation time without execution cost because whatsoever at high level all function calls are heavy so their is no point in worrying about the fact the call is virtual. – Oliv Jun 16 '20 at 11:40
  • 1
    Type erasure or runtime polymorphism (abstract classes) might be an option to get rid of template. – Jarod42 Jun 16 '20 at 11:42
  • @Someprogrammerdude yeah I realized that myself when the linker error hit me. I was just trying to not categorically exclude a circumvention possibly existing that I for some reason could not imagine. I'm roughly aware of PImpl, yeah. But never *really* used it (only maybe somewhat similar concepts to avoid dynamic allocation, but that's not a requirement here) I need to read up on "type erasure". – sktpin Jun 16 '20 at 12:56

0 Answers0