Recommendations for include order / stream operators?

[nilsvu]

The Catch2 documentation states that any custom stream operators (or equality operators) must be declared before including Catch2 (https://github.com/catchorg/Catch2/blob/devel/docs/tostring.md#top). My question is how to accomplish this best while following other established C++ guidelines.

My project is split into lots of libraries. Each library has data structures with stream operators. Each library has a Catch2 test executable. I would usually compile files like this into test executables:

// STL and third-party headers first
#include <string>
#include <catch2/catch_all.hpp>

// Project headers second
#include "MyLibrary/MyDataStructure.hpp"  // defines stream operators
#include "MyOtherLibrary/TestUtilities.hpp"  // also includes Catch2

TEST_CASE("...") { ... }

This structure fails to compile, because Catch2 can't find the stream operators.

Do I have to move the Catch2 include to the bottom? But how is that possible when including other headers with test utilities that need to include Catch2? Relying on the include order so much seems very fragile. So do I have to add forward-declaration files for all stream operators and include them at the top? That also seems very fragile, and requires me to make a lot of invasive changes to the project (lots of stream operator declaration files, probably same for equality operators). And this breaks if the declaration headers are included through other headers.

Does anyone have suggestions for me?

[horenmar]

I've never seen that include ordering in a project before. The usual order is

<this project>

<library A>
<library B>
...

<system headers>

This structure fails to compile, because Catch2 can't find the stream operators.

This is suspicious, can you provide the error?

Otherwise I agree that relying on the include order is fragile, but to the best of my knowledge there is no workaround in this case. The issue boils down to wording on template instantiation that means that when Catch2 declares its internal stringification function, all types that are to be stringified with op<< must've already declared the operator (because there shouldn't be difference between instantiating the template immediately versus later).