Code Bloat g++
Martin v. Loewis
Sat Feb 19 16:02:00 GMT 2000
> Hmm. No comments on my "implicit #pragma-inferface" idea.
> (See http://gcc.gnu.org/ml/gcc/2000-02/msg00515.html )
> If people think it wouldn't work or be too difficult,
> that I understand.
I don't know what kind of comments you were expecting. You said
# It seems like if we are going to do pre-compiled headers
and I thought "so perhaps not this year".
On your #pragma stuff, I think there is a number of problems with
it. First, the idea of compilation repositories does not really work
in my experience. I quite like the 'filter' mode of the compiler: one
input file, one output file. Any additional outputs will produce a lot
of pain, starting with getting the Makefiles right.
Then, I think the problem with extensive debugging information is
partially a misperception on the user side, and the rest has little to
do with header files. *If* there is really a lot of overhead in debug
information, it comes from the .cc files, not from the .h files.
Inline functions may indeed contribute to the large debugging
information. However, this is not due to duplicate out-of-line
instantiations across translation units, but because of duplicate
inline copies. You cannot share debug information for the inline
copies, since they have different register and stack usage every time
they are inlined.
Pretty much the same holds for template functions. Debugging
information is generated for instantiations, not for the template
themselves. Different code is emitted depending on the template types
- perhaps even different functions are called inside different
instantiations. So you cannot share much information across
instantiations with different template parameters. Instantiations with
the same parameters may share debug information - unless the
instantiations are inlined.
So, I'm not sure what your proposal would give us. Also, you didn't
indicate who you would implement your approach - which, I think, is
more difficult than writing it down.
More information about the Gcc