Re: [Boost-users] Issues trying to use boost::unordered_map

Subject: Re: [Boost-users] Issues trying to use boost::unordered_map
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-11 19:24:39

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.