On 11/10/2016 21:28, Leon Mlakar wrote:
Ahem ... there should be a book written (I can suggest the title: "The use and abuse of #include directive") about improperly structured #includes ... probably a multi-volume set full of horror stories.
The include order:
1. System/standard header files 2. Other libraries header files 3. Project header files
usually works best, unless there is a very good reason to change it.
One rule of thumb that I try to follow is to include the header file for the current cpp file first, before anything else (except stdafx.h, if you're using that). This helps ensure that the .h file contains all the forward references and/or #includes that are actually required by the interface, which makes it easier to consume elsewhere. (Although you might miss something that's in your stdafx -- but that's not usually an issue unless you're also consuming it from a different project.) ie. CoolWidget.cpp has these includes: #include "stdafx.h" #include "CoolWidget.h" #include <other system includes> #include <other library includes> #include "other project includes" Having said that, *properly written* include files should be includable in any order, since they should include what they need to depend on and should be ignored if included more than once. (This is not reality, though.) Where you get tripped up is when some headers try to interfere with others via #defines (eg. settings), or you try to integrate components that disagree in ABI-affecting ways. (I recall a recent thread mentioning issues when trying to use a library that uses Asio in an application that also uses Asio, but with different settings.) I'm interested to see what effects modules have on this, once they exist, since theoretically they're supposed to be immune to being affected by #defines like this and yet some libraries are still going to need to provide ABI-affecting configuration options.