A few top-level comments on this thread:
1. The C++ community has split into two sub-communities. One is very heavily focused on template metaprogramming. The other is doing more "traditional" object-oriented programming. The kinds of programs written by these two communities are drastically different, even though, obviously, there is overlap between the two, mixed programs, etc. But, programmers in one camp tend to think that their style is "very common" while that of the other camp is "fancy" or "complicated". The truth is that both are now mainstream uses of C++, and we need to try to work well with both kinds of code.
2. I don't think we should be make any changes at this point without a relatively comprehensive benchmarking effort. That means more than a few programs, compiled on multiple architectures, with measurements of both compile-time and runtime performance. I'd suggest that tramp3d is fine, but I'd also suggesting looking at KDE, Boost, and libstdc++-v3. I'd try to measure total compilation time, total code size, and some measure of performance. (Since C++ inlining should generally -- but not always, of course -- result in smaller code due to removal of calls, code size is probably a rough proxy of performance.)
3. Richard's attempt to discount stuff from being counted unnecessarily in return statements makes sense to me.
4. I don't see any reason to think that an inliner tuned well for C++ would not also work well in C, though the opposite might not be true. (People using inline heavily in C are generally writing code that looks relatively similar to OO C++ programs.)
5. However, it really might be sensible to have the C++ front end treat "inline" as a command, rather than a hint, by default. It might be that explicit uses of inline should be pretty much unconditionally honored. (I'd say that functions defined in a class, but not marked inline, should not be given this behavior. That's partly because other compilers already treat "inline" in a class definition as more emphatic than just defining the function there, so there's a body of existing code out there that relies on this.) I suspect that having the C++ front end treat "inline" as a command would fix most of the C++ inlining problems without requiring any tuning of the inlining algorithms. Has anybody experimented with that potentially much less intrusive fix?
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
