I'm refering to the use of the "inline" keyword, of course.
You're right that some modern compilers will inline without it,
across compilation units, and according to the profiler data.
Some compilers I've worked with use the "inline" keyword to bias the "inlining
score" that is used to determine if a function is going to be inlined.
Most of the compilers I've worked with require the code to be visible in the
compilation unit for the inlining to take place (i.e. no link-time inlining).
In such cases, the "inline" keyword is required to prevent the "multiple
definition" error from arising.
It does.
As with any rule, it can be violated when there are overriding
reasons to do so. But these are rare in application code, and I
can't remember every having seen a template definition in
application code in production software.
In practice, this isn't that restricting. "Application"
generally means dealing with known types anyway, unless you need
dynamic dispatch. Templates tend to be restricted to lower
level, very stable libraries. Libraries that are considered so
fundamental that 1) upgrading to a more recent version is
considered a major undertaking, much like moving to a new
version of the compiler and 2) if you do it, you recompile
everything and run the entire regression test suite again,
before going further.
I disagree with your assessment, but I suppose it depends on your application
domain. I find that almost all of the "application" code I've worked on use
templates at the application level.
Do you mean that you don't _use_ templates at the application level (not even
using their definitions from a library), or that you merely don't _define_
application-level templated entities?
-dr
