On Thu, 2015-01-29 at 11:43 -0500, Justin Ross wrote: > ... > > This makes the file robust against any change of transitive includes > > because the dependencies of its dependencies change.
We call this refactoring, and we should be doing it all the time. > > > > At the obviously quite tremendous risk of speaking from too little > experience with C projects, this seems too simple. *If you don't control > the header dependencies of a third party project*, I agree it makes sense > to code defensively. > > But if it's inside your own source project, those redundant includes aren't > really defending you against anything. I don't think this is defensive coding - it is correct coding - it means that every header file stands alone irrespective of changes in its dependencies. It makes the code better decoupled at the "physical" structure level and makes changes to the code better localised, which is strongly beneficial even if you control all the source. In any case there should be very few places where this actually comes up to be honest. It should only come up with headers that define types that are always used as values and not references. So I'd expect something like proton/types.h (or whatever it's actually called) to be used in nearly every header, but proton/transport.h to be used hardly anywhere (nowhere?) since the types it defines are always used as references. I think that starting with a picture in the documentation that you think is confusing and then deciding to change the structure of the includes to simplify the picture is putting the cart before the horse. Of course if the picture genuinely represent a bad project structure then we should change that structure, otherwise just omit the picture, or use directives to simplify irrelevant bits of it (assuming these exist). Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
