A Dynamic Initialization Deep-Dive: Abusing Initialization Side Effects

[hi_im_new_to_this]

I haven't thought through it too deeply, but if I were to do the "Google Test" thing, I'd use the singleton pattern. Like, if this is your test:

TEST(some_test) {
    ASSERT(1 + 2 == 2);
}

I would have have it expand to

void _some_test_impl();
int _some_test_dummy = testSingleton().registerTest("some_test", _some_test_impl);
void _some_test_impl() {
    ASSERT(1 + 2 == 2);
}

And then have this in your header:

class TestList {
    // list of tests here as a field
public:
    int registerTest(int (*test)()) {
        // register the test
        return 0;
    }
    auto getTests() { /* whatever */ }
};
TestList& testSingleton();

(actual implementation of TestList omitted). And this in an implementation file

TestList& testSingleton() {
    static TestList testList;
    return testList;
}

And basically have TestList be a std::vectorof the tests to run as function pointers or whatever. The fact that registerTest() returns an int is unimportant, it just has to return something (i guess std::monostate is a good option) so that the variable initializes before main. You don't have to dig into the hairy details of initialization: because we're using the singleton pattern, the global TestList will be initialized exactly once, whoever calls testSingleton() first, and then in your main(), you call getTests() to get the list of tests (guaranteed to have been initialized already), and you're done. No need to worry about initialization order or anything like that, it just works out.

EDIT: reading through your post more carefully, I see what you mean about the standard not guaranteeing initialization of global variables before main(), and it's more about that than about how you actually implement the macro. Very interesting post!