Re:Killing the C++ Modules Technical Specification
by corysama on Wednesday October 11, 2017 @10:41AM
(#15450139)
Now I'm wondering what is a good way to measure my project's top 100 redundantly instantiated templates.
Re:Killing the C++ Modules Technical Specification
by colanderman on Wednesday October 11, 2017 @12:44PM
(#15451106)
find build/ -name \*.o -exec nm -C \{} \; | egrep ' W .*<' | sort | uniq -c | sort -n
is what I use. This lists all templated, implicitly instantiated, non-inlined symbols in increasing order of number of uses. Note that templates internal to libstdc++ will also show up and you may want to instantiate these too.Note that explicit instantiation won't decrease the size of your object files, only the compilation time. (By default, the linker throws away duplicate instantiations.)
Re:Killing the C++ Modules Technical Specification
by fnord123 on Wednesday October 11, 2017 @05:02PM
(#15453464)
gcc has -ftime-report which is kinda opaque but still interesting.
Re:Killing the C++ Modules Technical Specification
by petters on Wednesday October 11, 2017 @12:05PM
(#15450804)
Doesn't this prevent a lot of inlining? Or perhaps the compiler is smart enough in most cases?
Re:Killing the C++ Modules Technical Specification
by colanderman on Wednesday October 11, 2017 @12:11PM
(#15450840)
No change to inlining. The definitions are still in the headers and the compiler will still eagerly inline them if they are defined in the class declaration (as typical) or defined outside the class declaration and explicitly marked inline (less typical).
(Whether inlining of non-trivial methods is desirable is - and in fact recently was - a discussion for another HN story.)
(Of course this doesn't alleviate the problem of parsing the template header files over and over.)
See the section on explicit instantiation here: http://en.cppreference.com/w/cpp/language/class_template