Mark Mitchell <[EMAIL PROTECTED]> writes: | 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.
The world might be simpler if typical uses fall into either of those camps. We would just provide switches -finline=template-abuse -finline=traditional-oo and leave the rest on its own, as a punishment for not having decided on a side. In effect, the extremes do not characterize either communities, as to the way they think of inline. Typical programs use combinations of both styles, e.g. heavy (ab)use of templates and conventional OO-styles. I do not believe that typical uses of "inline" by either of those communities is for "fun". Parenthetically, I've been told recently that after MS managers asked their compiler developers to use C++ libraries in their codes, their support for abstractions have much improved. :-) [...] | 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 For "simple enough" functions. Here, by "simple enough" function, I mean a metric that uses counts very close to program source level, not insns (in particular we must pay special attention not to artificially inflate the measuring by most temporaries introduced by tree-ssa and such.) It seems to me that most of the inlining frustration comes from the fact that inlining requested from source code is usually confused with the compiler discovery of more opportunities to inline (i.e. -finline-functions), and as such arguments for the latter tend to overwhelm program's request at the source level. | 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.) In-class definitions of inline functions is very common for small functions -- typically trivial accessors. The artificial distinction you're making does not make much sense to me, for practical purposes. I do agree that measurements are necessary. -- Gaby
