He notado que, al menos bajo c++17 ISO con g++, std::type_index parece coincidir de manera confiable con la igualdad en el caso de clases polimórficas cargadas dinámicamente a través dlsym . Esto parece habilitar una pequeña y agradable validación en tiempo de ejecución de las interfaces antes de crear instancias de clases de complementos. Por ejemplo:

 template<typename T> std::shared_ptr<T> CreateImplOf(std::string pluginName, std::string className) { auto it = m_pluginDict.find(pluginName); if(it == m_pluginDict.end()) return nullptr; auto& plug = it->second; const std::type_index& iface_info = plug.GetInfo()->getInterfaceTypeInfo(className.data()); if (iface_info == std::type_index(typeid(T))) { std::cout << "SUCCESS! type " << iface_info.name() << " match impl interface... " << std::endl; } else { std::cout << "FAILURE! type " << typeid(T).name() << " DOES NOT match impl interface " << iface_info.name() << "... " << std::endl; throw std::exception{}; } void* pObj = plug.CreateInstance(className); return std::shared_ptr<T>(reinterpret_cast<T*>(pObj));

Pero como tengo el presentimiento de que este comportamiento no está definido en el estándar, me pregunto cuánta confianza debemos poner en esta verificación de tiempo de ejecución.

En un mundo ideal, la igualdad de std::type_index entre dos interfaces implica compatibilidad ABI entre ellas, de modo que invocar métodos virtuales a través de cualquiera de las dos interfaces estaría bien definido, pero casi seguro que no vivimos cerca de ese mundo ideal, pero, ¿exactamente qué expectativas se pueden tener al pasar esta verificación de tiempo de ejecución? ¿Podemos suponer que esto funciona en la misma versión del compilador solo para la misma definición de clase exacta? o ni siquiera eso en general?