On 09/10/2014 10:16 PM, Matthew Wilcox wrote:
Woah, woah, woah, what is this craziness? You shouldn't ever rely on
implicitly included files.
It is fine I do not mind the language ;-)
I'm not going to fight you over this *I could really care less*, but for
the record you are wrong.
If header B has an API like
typeA1 b_foo(typeA2 a2, typeA3 a3);
where typeA1, typeA2, typeA3 are from an included header A
and code in C.c needs the use of b_foo(), or even say b_foo is a vector
that C.c needs to implement. Then typeA1, typeA2, typeA3 are explicit
by B not implicit.
Implicit is if B has private structures with say typeXy from header X
but my code does not need to declare or implement any X types. in order
to use public API of B.
The mathematical proof as I said is. If B can be changed in such a way
that C.c code will not compile, but the only changes to C.c will be an
#include <X> directive "then X is implicitly included from B".
But if for C.c to compile after the changes to B more than #include
fixes, but actual code need changing, "then X is explicitly included from B"
That said. my opinion from 35 years of coding (Yes 1989) is that since there
is no tool that can measure [Ax] then the only sane/logical programming model
is actually the "minimal set". Which has performance merits as well.
And when a developer changes such an important aspects of B, its includes
chain, he needs to pay and fix miss-compiling users. All efforts measured,
this is a least-maintenance effort. My $0.017