* Ioannis Vranos:
Still, I am not satisfied by the answers.
If you may clarify to these, it would be great:
This is a tool subject, and the discussion turns to providing
documentation by "hacking" the language.
Parse error.
What kind of more technical documentation do you have in mind than this:
-- SomeFunc.h
// SomeFunc() does whatever
void SomeFunc();
-- SomeFunc.cpp
#include "SomeClass.h"
//...
void SomeFunc()
{
// ...
}
Remove
* The comment (can't be checked by the compiler)
* The #include.
* The repeated declaration of the function signature.
Move
* The body of the function to the header file.
Add
* 'inline'.
Now the function (assuming it's a small one) is self-documenting.
For something more, there are documentation tools out there (even for source code-level
documentation).
The main documentation is always the compilable source code. Comments
are second class, because they can't be checked and easily get out of
synch in the cases where they're correct in the first place. Separate
documentation is even worse.
When you only have a header file, no implementation file, there is one
less file to compile separately.
[Below it seems something's wrong with the quoting levels. However]
Also, in the
contrary, if you decide to change only one function definition, you will have to recompile
every compilation unit that uses it, if you have made it inline.
What kind of declarations does it cut down?
It cuts down on _redundancy_ of declarations, the repeated function
signatures.
Redundancy is bad both because of more work, and because of the
possibility of unnoticed differences.
As of compiler invocation, are you talking
about one additional file to compile while avoiding to recompile the rest when you decide
to change the definition, vs compile *all* the rest that make use of the function, once
you decide to modify the definition.
Parse error. I gather it's an attempt at phrasing a false dilemma? ;-)
But it will inline whenever it can for the ones that you defined as
inline and have placed in scope before the function use in a
translation unit,
No, that is incorrect.
The point that's been stressed (I feel) a thousand times in this thread
is that not only can you not rely on that.
With modern compilers you can rely on the opposite: that the compiler
will do the job much better you can, and the more information you give
the compiler to do that job, the better job it does.
while it may not inline when you
make it a regular function with one definition in another
translation unit.
That's almost a given as of 2005, because few C++ compilers so far
do a decent "whole program optimization" which is needed for that.
Essentially that, for those hooked on needless optimization, one should
give the compiler the most information possible to do the very best job.
And that means preferably using 'inline' functions and in-class definitions.
Lest I be misunderstood here: I'm not recommending that unconditionally,
only for the mindless micro-optimization-freaks.
In this way you will get more inlining, and not less.
The effect depends on everything. The complete program, the compiler,
system, options, everything. All you know is that _whatever_ you're asking
the compiler to optimize for, the more information you make available to it
(like the source code of functions), the better a job it will generally do.
I am not sure I see any benefits of this.
Naturally: if the code doesn't need to be correct it can be infinitely
optimized! Great idea. Correctness, goodbye!
The way I view it, is that what you gain is only
Incorrect.
extra pain to recompile everything on any change of the inlined
function definition
Yes, there I agree very much.
as also possible extra, unintended code bloat,
Nope. Or rather, anything's possible, but it's extremely unlikely. On
the contrary, if you the compiler to optimize for code space, it's much
more likely to do a perfect job if you give it maximum information.
while there isn't any source code benefit of this.
Incorrect.
Cheers,
- Alf
