I don't know about any toolchain that is able to collapse multiple instantiations of same template with different types but otherwise identical code (ie. std::vector<Foo> and std::vector<Bar>) and on many codebases I've found out that these template instantiations are large part of resulting binary size.
While it's probably simple to write programs that results in small binaries it probably involves not using large parts of language. In my opinion it is often more reasonable to use straight C (which also makes performance characteristics of program more obvious in any case).
You mean identical source code or identical assembly code?
I would expect that compiler strip away typdef'ing so unless Foo and Bar are really different, only one copy of the code should exist.
Yes, you can probably defeat this heuristic by doing a couple of pathalogical things, but I expect it work unless you're actively trying to defeat the system.
identical assembly. No C++ compiler that I'm aware of does that.
e.g., std::vector<Foo * > and std::vector<Bar * > generate identical code for whatever you do, as they both only deal with the pointer, never dereference it in any way. Also, in code like
template <class T> T get(T x[], int i) { return x[i]; }
on a 32 bit platform, get<int>() and get<char* > generate the same machine code, whereas on a 64 bit platform, get<long>() and get<void * >() generate the same machine code.
No C++ compiler that I'm aware of folds these cases into one; The C# generics do (not sure about non-generic code with identical final machine code). I would be surprised if idiomatic C++ code could be shortened by more than 50% by a compiler that did. However, if you write your code for column-major access, the binary can go down 90% if the compiler did that.
The C++ committee answer to this is to use "partial template specialization". I'm hoping all the standard libraries I use such as Boost etc have already done this to avoid code bloat.
But I agree that it would be nice if the compiler did this automatically.
While it's probably simple to write programs that results in small binaries it probably involves not using large parts of language. In my opinion it is often more reasonable to use straight C (which also makes performance characteristics of program more obvious in any case).