Re: inline request and compiler rejection
On Mar 20, 4:55 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 19, 11:40 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
Inlining increases coupling.
Not, it doesn't, except in an extremely shallow sense.
I'm not sure what you mean by "shallow". It increases
compile time coupling significantly, which is extremely
important in anything except trivially small applications.
In the first place, that's not "coupling" in any meaningful sense.
It's coupling in the most classical sense.
In the second place, as I already posted, I have not seen a
prohibitive effect on build times. The projects I work on are
not "trivially small."
If you're working on libraries, you won't see them. Your users
will. (If you're using dynamically loaded objects, it may mean
the difference between having to relink and recompile, and not.)
Furthermore, changing the signature of an inline function, in
any syntactically and semantically backward-compatible way,
requires only one source change for an inline function, but
two changes for a non-inline function.
But why would you change the signature if you don't change the
contract.
Usually to improve error-checking. Occasionally, to add an
argument with a default value, although I do find that
distasteful at best.
But neither are particularly frequent. Significantly less
frequent, at any rate, than changing details of the
implementation.
And if you change the contract, you have to at least look at
every place the function is used. A lot more than just one
or two places.
The places it is used are additional to the places in which
you declare it, not instead of.
Yes, but it does mean that one or two places more or less
doesn't make a difference.
That's why the desicion to change the signature usually rests in
other hands than the desicion to change the implementation, and
why it is important that the implementation and the signature
reside in different files.
That is complete nonsense.
No, it's good software engineering.
Moreover, separating the definition from the prototype has
a staggering syntactic overhead in C++, particularly for
member functions and templates.
It could be simpler, but I've never found it to be a
particular problem. And I don't know how you can maintain
the public interface and the implementation in two separate
files otherwise. (Of course, a good tool set helps here;
you don't actually write the boilerplate yourself, the
machine does it for you.)
As always, you are entitled to your opinion. I'm not sure why
you have taken it as your personal responsibility to chastise
me every time I express an opinion you do not care for.
There are matters of taste, and there are matters of basic
software engineering. I tend to jump on anyone who recommends
bad engineering.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34