type_id is not consistent across modules (executable and dynamic library).

[Dragnalith]

I am questionning the following implementation of type_id:

struct type_id_ptr {
	// Having a static data member will ensure us that it has only one address for the whole program.
	// Furthermore, the static data member having different types will ensure it won't get optimized.
	static constexpr T* id = nullptr;
};

I think the assumption is wrong. A static variable is not global to the whole program, but just the whole module. I am expecting the type_id value inside two different DLL both using kangaru will not have the same value.

Since type_id is a private class, I do not imagine any situation where people will transfert type_id accross DLL. So it looks to be a minor bug for now.

[gracicot]

Also far as I know during dynamic linking, it should resolve static variables to have the same address, if all shared libraries are loaded in the correct order. I don't really know how it works on Windows, but I'd expect something similar.

I never analysed what happened when trying to load a dynamic library through dlopen though.

A actually asked the question recently on code review, and it seemed ok: https://codereview.stackexchange.com/q/209950/118376

The type_id and type_id_t type is actually exposed in the public API, but it doesn't matter. If the type id is different across shared libraries, then the container simply can't be passed across library boundary safely.

[gracicot]

Can you try this test project? https:/gracicot/kgr-shared-test

I added a simple test that compares the type id inside a shared library and an executable. On my setup both ids are true and singles are working as expected.

[gracicot]

This is fixed by #97. All type IDs are simply generated hashes from the type name.