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. [Ax] 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 sigh Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
