Not to mention link times: templates generate HUGE mangled symbols, with corresponding increase in memory and time as all those strings have to be stored and string-compared.
I've long wondered about why doesn't any C++ compiler implement symbol hashing? As in: replace symbol names with symbol hashes (SHA1) in the symbol table, and emit an extra section that maps hashes back to mangled names. Linker could do all of its work using hashes, and would map them back to regular symbol names only when generating the final debug info file.
The OCaml compiler uses hashes for some symbols. It has to have extra discrimination code in the linker to deal with potential collisions, and it can reject valid programs because of this. That's in theory, because I've never seen a program rejected, except for a synthetic program that someone made to demonstrate hash collisions ...
It is not as fast as it could be. It is an implementation of ordinary hash table, meaning that also a successful search requires comparing two strings several kB long. What I propose is to reduce ALL symbols to their hashes (SHA1 is 20 bytes) and to "dehash" them only after linking has been done.
Collision in hashes is of only theoretical interest when you consider SHA1 or SHA256.
I've long wondered about why doesn't any C++ compiler implement symbol hashing? As in: replace symbol names with symbol hashes (SHA1) in the symbol table, and emit an extra section that maps hashes back to mangled names. Linker could do all of its work using hashes, and would map them back to regular symbol names only when generating the final debug info file.