On 10/23/2017 04:17 PM, Jonathan Wakely wrote: > On 23/10/17 17:07 +0200, Michael Matz wrote: >> Hi, >> >> On Mon, 23 Oct 2017, Richard Biener wrote: >> >>> I guess so. But we have to make gdb happy as well. It really depends how >>> much each TU grows with the extra (unneeded) include grows in C++11 and >>> C++04 mode. >> >> The c++ headers unconditionally included from system.h, with: >> >> % echo '#include <$name>' | g++-7 -E -x c++ - | wc -l >> new: 3564 >> cstring: 533 >> utility: 3623 >> memory: 28066 > > That's using the -std=gnu++4 default for g++-7, and for that mode > the header *is* needed, to get the definition of std::unique_ptr. > > For C++98 (when it isn't needed) that header is much smaller: > > tmp$ echo '#include <memory>' | g++ -E -x c++ - | wc -l > 28101 > tmp$ echo '#include <memory>' | g++ -E -x c++ - -std=gnu++98 | wc -l > 4267 > > (Because it doesn't contain std::unique_ptr and std::shared_ptr before > C++11). > >> compile time: >> % echo -e '#include <$name>\nint i;' | time g++-7 -c -x c++ - >> new: 0:00.06elapsed, 17060maxresident, 0major+3709minor >> cstring: 0:00.03elapsed, 13524maxresident, 0major+3075minor >> utility: 0:00.05elapsed, 16952maxresident, 0major+3776minor >> memory: 0:00.25elapsed, 40356maxresident, 0major+9764minor >> >> Hence, <memory> is not cheap at all, including it unconditionally from >> system.h when it isn't actually used by many things doesn't seem a good >> idea. >>
I think the real question is whether it makes a difference in a full build. There won't be many translation units that don't include some other headers. (though of course I won't be surprised if it does make a difference.) If it's a real issue, you could fix this like how the other similar cases were handled by system.h, by adding this in system.h: #ifdef __cplusplus #ifdef INCLUDE_UNIQUE_PTR # include "unique-ptr.h" #endif #endif instead of unconditionally including <memory> there, and then translation units that want unique-ptr.h would do "#define INCLUDE_UNIQUE_PTR" instead of #include "unique-ptr.h", like done for a few other C++ headers. (I maintain that IMO this is kind of self-inflicted GCC pain due to the fact that "#pragma poison" poisons too much. If #pragma poison's behavior were adjusted (or a new variant/mode created) to ignore references to the poisoned symbol names in system headers (or something like that), then you wouldn't need this manual management of header dependencies in gcc/system.h and the corresponding '#define INCLUDE_FOO' contortions. There's nothing that you can reasonably do with a reference to a poisoned symbol in a system header, other than avoid having the system header have the '#pragma poison' in effect when its included, which leads to contortions like system.h's. Note that the poisoned names are _still used anyway_. So can we come up with a GCC change that would avoid having to worry about manually doing this? It'd likely help other projects too.) Thanks, Pedro Alves
