Thread: Templates and libraries-How does it work?

Originally Posted by baxy

I need some help to understand how templates work. So templates allow functions (classes) to work with generic variable types. As far as I understood the decision how the function is ulitmatly defined (whether it should accept int or long int ) happens at compile time. (Right?)

Yep. Whenever you call a template function, the compiler stamps out a new function while replacing the template type with the real type.

Originally Posted by baxy

So if I compile my libraries contiainig templates beforehand and then use them for compiling my main program afterwords, what happens then? how are my functions defined (int or long int or are they still generic) and how does this work?

That depends on your definition of a library. Is it in compiled form (i.e. static library or dynamic library)? If so, then it won't work at all unless you explicitly instantiate your templates for some type (and for DLLs, export them).
If your definition is just a bunch of source files that are compiled and templates in headers (e.g. boost), then it works just fine.

Originally Posted by baxy

is it a better practice to compile libraries in such cases or just make hpp files and compile them de novo each time , together with a main program?

Depends on your needs. If you get away with explicitly instantiating your templates for a few types and exporting these through a library, then it may be worth doing so as it will save you compilation time.
On the other hand, if you can't, then shipping those as headers is another alternative that's used. Boost (popular C++ library) does both. It provides some functionality through compiled libraries and some functionality through templates via headers that are included.

Originally Posted by manasij7479

You can try precompiled headers, but they are sort of messy.

Precompiled headers aren't meant for this purpose. They aren't meant for shipping to others. They are meant for speeding up compile times by allowing the compiler to translate the contents of possible many headers into a more efficient format to read and parse.

Originally Posted by manasij7479

If you want a better alternative, C++17 will have a module system.

As far as I know, the module system has not yet been voted into C++17, nor is it on track for C++17. At this stage, I believe it is merely a TS or something along those lines.

Originally Posted by manasij7479

So why do we not ship precompiled headers ?

...

If the compiler remains constant, can we use precompiled headers like a library ?

As you noted, they aren't standard. They're some internally used format used by the compilers. They won't interoperate and they can certainly break with different versions of the compiler and even different compiler settings. You can't, for example, use a PCH compiled with a C++ compiler for C and vice versa. Change some settings like runtime library and it fails again. Simply put: they're a means to speed up compile time, not shipping code to customers.
Compare with header files. They will always compile on all compilers and are much more resistant to compiler settings (assuming you've written standards compliant code).

Originally Posted by manasij7479

DIdn't know that, thanks!
So why do we not ship precompiled headers ?
Only reason I can think of is portability between compilers.
GCC just dumps its internal state, AFAIK.
Clang has a more sophisticated system, and I think their module implementation uses their precompiled headers logic at its core.
No idea what VS does.
If the compiler remains constant, can we use precompiled headers like a library ?

If the user is concerned about compile time, then they've already got PCH set up in their project, and they can throw your library headers into stdafx.h (or equivalent for other compilers), and it'll get precompiled the first time they do a build. It makes no sense to publish intermediate build products which most likely won't even work with their toolchain (or worse, appear to work but have unknown defects).

Not to mention, if your library API is so complicated that PCH makes a significant difference to compile time, then chances are I don't want to use your monstrosity in the first place. I am already having to include Windows.h, please don't make my life suck even more.

Originally Posted by brewbuck

Not to mention, if your library API is so complicated that PCH makes a significant difference to compile time, then chances are I don't want to use your monstrosity in the first place...

If only life was so easy. I'd be so happy if I could just get compile times in a few milliseconds.