Is requiring a certain order for #includes in c++ a sign of bad library/header design?

Question

I've used some very large scale systems and never seen a required order, but came across it recently. Does the STL or STD library or even Boost have any cases where certain includes must come in a certain order?

Answer 1

Does the STL or STD library or even Boost have any cases where certain includes must come in a certain order?

For the standard, the answer is emphatically, no. I imagine the same is true for Boost, though I haven't looked it up.

From the C standard:

Standard headers may be included in any order; each may be included more than once in a given scope, with no effect different from being included only once, except that the effect of including <assert.h> depends on the definition of NDEBUG (see 7.2).

the C++ standard has similar wording.

My preference is that headers should include their own dependencies, but I've worked with people who believe this to be 'wasteful'. In my opinion, not having headers include their dependencies is a worthless early optimization.

Answer 2

This definitely sounds like a bad design. If somehow a specific order was required, the library should provide one header that includes the other ones in the correct order.

As far as boost, and the STL, I'm pretty sure I haven't encountered this situation yet.