MotiveAPI 3.1.0 using std containers !!!
Posted: Sat Oct 11, 2025 1:53 am
Hi,
I'm surprised that the Motive API contains functions using std containers, which is against best practices. Indeed, if the client uses a different std version, there is a risk of crash.
STL types (std::string, std::vector, etc.) are not ABI-stable.
Their binary representation and allocation strategy vary between:
- Compiler versions (MSVC, GCC, Clang)
- Standard library implementations (libstdc++, libc++, MSVC STL)
- Build options (_ITERATOR_DEBUG_LEVEL, _GLIBCXX_USE_CXX11_ABI, etc.)
- CRT linkage (/MD vs /MT)
This means passing a std::vector<int> from a DLL built with one configuration to an EXE built with another can lead to heap corruption, crashes, or memory leaks.
And this is exactly what I'm currently facing.
Best regards,
Vincent
I'm surprised that the Motive API contains functions using std containers, which is against best practices. Indeed, if the client uses a different std version, there is a risk of crash.
STL types (std::string, std::vector, etc.) are not ABI-stable.
Their binary representation and allocation strategy vary between:
- Compiler versions (MSVC, GCC, Clang)
- Standard library implementations (libstdc++, libc++, MSVC STL)
- Build options (_ITERATOR_DEBUG_LEVEL, _GLIBCXX_USE_CXX11_ABI, etc.)
- CRT linkage (/MD vs /MT)
This means passing a std::vector<int> from a DLL built with one configuration to an EXE built with another can lead to heap corruption, crashes, or memory leaks.
And this is exactly what I'm currently facing.
Best regards,
Vincent