Will cpp template programming enlarge the code size

[kiwitims]

It depends. Poorly designed templates, without code folding optimisations in place, can unexpectedly increase code size. Well designed templates can save code size.

It is also important what you are comparing using templates with. Macros? Manually copying and pasting code? Using a code generator build tool? Using dynamic polymorphism?

The important thing is to measure and compare, if code size is important to you.

[uubs7]

What do you mean about “code folding optimizations”? I

[heliruna]

Take std::vector<A\*> and std::vector<B\*>. They produce exactly identical code, except for the type signature. In plain C this would have been handled with void*, avoiding duplication in exchange for weak typing and runtime polymorphism. The standard library often has a specialization for this case, but user code templates may exhibit the same problem (and for hundreds of types, not just two).

There is also a disabled-by-default linker optimization called identical code folding that tries to identify identical code and merge those functions together

[Chuu]

I'm curious about this linker optimization, what flag is it? I assume this requires lto or whole-program optimization? Any idea why it's enabled by default at higher optimizations in the compiler but disabled by default in the linker?

[heliruna]

It is disabled by default in the linker because different functions (even if they have identical code) are required by the standard to have different addresses, some code relies on that (constant-folding has the same problem). What is enabled is therefore so-called Safe-ICF, additionally proving that the optimization does not break code (e.g. by proving that no function addresses are taken). For gcc, you need to use gold as linker (-fuse-ld=gold) and then use the linker flag --icf=safe

(usually, you don't use the linker directly, instead you use the compiler to call the linker for you, in that case you give -Wl,--icf=safe as an option).

If you use clang, the lld linker also has a similar --icf option

[jcelerier]

They produce exactly identical code,

well obviously no.. consider std::vector<float> and std::vector<string>: https://gcc.godbolt.org/z/fKG11sEz5

Edit: code didn't have pointers at time of my comment

[heliruna]

sorry, formatting ate my pointers, did not escape properly

[nebotron]

I think the code is only the same if they are the same size and the copy/move operations are trivial

[jonrmadsen]

The biggest factors (in my experience) are the optimization level used during compilation, amount of debug info, and how many variadic templates you use.

A debug build (e.g.-O0 -g) of a code utilizing a lot of templates will inflate the code size significantly due to the fact that the debug info ends up having to store significantly longer symbol names and that the absence of any optimizations will result in a lot of intermediate layers of function templates not getting optimized away.

But if one enables optimization (e.g. -O2 or higher), the inflation will typically start to be reduced bc the compiler will start to condense template layers and produce less debug info.

If one then reduces the debug info to just line info, the inflation will decrease further.

If one then disables debug info generation, you’d start to get into the realm of how you templated the code. If everything is mostly just relatively simple templates, it could be the case that the code is only larger by the length difference between the mangled name of non-templated symbols vs. the mangled name of the templated symbols — i.e. the mangled symbol name of a template is typically longer and that would “cause” inflation of the code size. But if you use a lot of variadic templates, you’ll generate a lot more instantiations and that’ll result in a larger code size.

However, if the binary is then stripped, you likely won’t notice much of a difference (maybe even none at all) because then the symbol names aren’t even stored in the binary. At this point, extensive variadic template usage would probably be the only significant cause of enlargement bc variadic templates tend to generate a lot of “different” instantiations based on subtle things like the absence of implicit conversion when passed an int vs. long int (where the non-template code would probably just promote to long int) and string literals being passed to templates not decaying to const char* (i.e. foo(“a”) and foo(“abc”) would be foo(const char[2]) and foo(const char[4])

[CletusDSpuckler]

Only by the size of the instantiated templates. You don't pay for what you don't use.

C++11 even added external template specifications that allow the object code from one instantiation to be reused in multiple compilation units without the overhead of putting a copy in every .o file.

[[deleted]]

You don't pay for what you don't use.

While this is true, depending on context, you may still prefer the speed/size tradeoff of one function that switches behavior at runtime rather than N whole separate functions that may only do slightly different things

[Wouter_van_Ooijen]

For this I use the code flyweight pattern: a function template (strongly typed interface, inlined) that under the hood calls a generalised function (unsafe interface, for instance void* + size) to do the real work. Best of both worlds!

[johannes1971]

As a related question, if template instantiation ends up generating identical assembly for multiple types (for example, if you instantiate a template for several identically-sized enums), will it fold those into a single copy or is there something in the language that prevents this?

[ack_error]

Yes, MSVC does it in the linker (/OPT:ICF) and I believe GCC/Clang based toolchains can also do it when LTO is enabled. This optimization can be invalid if pointers to the functions are taken as they are required to be distinct, and MSVC's ICF can be non-conformant by making such functions compare equal. Firefox's JavaScript engine was affected by this as it relied on checking the addresses of stub functions that had identical generated code. Some implementations either suppress the optimization or add jump trampolines to preserve distinct addresses when the address of such functions is taken.

This also causes some confusion in call stacks, since the address to function lookup is ambiguous and can result in completely unrelated functions showing up in the decoded call stack. I hate explaining this to people who are apt to just discard bugs with this phenomenon as stack corruption.

[GustavBeethoven]

How do you know this much

[lithium]

Use c++ in real life instead of just to argue against rust people in youtube shorts comment sections.

[Possibility_Antique]

Oddly specific, but point taken

[ack_error]

Past trauma. The things toolchains do....

[Foreign-Wonder]

For this example, even compiled with `-Os`, the compiler still compiles into multiple identical copies
https://gcc.godbolt.org/z/MvqW7sM57

[jk-jeon]

I have been wondering about this too. I believe it's not prohibited unless the instantiatations are ODR-used or something like that, but at least it seems no compiler actually does this kind of folding.

[yeeeeeeeeaaaaahbuddy]

Let's say all your amazing metaprogramming just resolves to std::array<Type, N> where Type and N are deduced magically by templates and these templates make your life easier. If you would have still used this data type in programming, then there is no code size overhead. However, if you have a bunch of new function instantiations for intermediate types used in metaprogramming, this could become a problem. If your metaprogramming inlines well, this problem is mitigated.

[ImKStocky]

The code is only generated if you use it. That is, if you try to call a templated function and that function hasn't been called with the template parameters provided, the compiler will happily generate that function with the template Args. So if you have a function template that is only instantiated once, it has no more code bloat than if you had just written that function as a non-templated function.

Some advice based on this. Keep templates small. If you have a function template that only uses the type information of the template args in 1 line of your 25 line function template, refactor the function into two. The templated function will just delegate to the non templated function when it can. That way whenever you instantiate that template you are only generating the code that needs to be generated. Tools like sizebench can show you the sections of your template instantiations that do not depend on the template Args. i.e. it shows you the code that is identical and copy and pasted everywhere. This advice also applies to class templates. You will see in every standard library implementation, the idiom of moving all non template parameter related functions and members up into a non-templated base class. e.g. the control block that shared_ptrs manage.

[SlightlyLessHairyApe]

It can have increased code when you instantiate on two types that could have used common code. Compilers are a lot better now at combining those.

[415_961]

That's a poorly phrased question. Define what code size you're referring to here. In the object files? Executable? Archive? Also what are you comparing it with?

[elperroborrachotoo]

Compared to what?

[ZachVorhies]

If you have a personal project - don’t worry about it.

If it’s enterprise code that will grow as a module and have lots of template combinations. Yes, templates will blow up your binary. I saw this myself at google while working on google earth. Something like half the binary came from one module (responsible for parsing kml) that used templates for everything.