MotiveAPI 3.1.0 using std containers !!!

[vsm]

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

[steven.andrews]

Hi Vincent,

Thank you for the detailed post and for taking the time to call this out. You are correct that exposing STL containers across DLL boundaries can introduce ABI instability, and what you described is consistent with what we would expect if the client build configuration does not match the one Motive was built with.

At present, the Motive API does make use of std:: types in its public interface, which means the DLL and client project must be compiled with compatible compiler versions and flags. Reworking this boundary would require significant refactoring, as there are a number of occurrences of STL types throughout the current API. Because of this, it is not something we can address quickly, but it is something we may look into for the future.

In the meantime, the best workaround is to match your project’s build configuration with the one used by the Motive API samples. You can find those in: C:\Program Files\OptiTrack\Motive\Samples\MotiveAPI

If you can successfully build and run the samples, you can copy that toolchain configuration into your own project to ensure binary compatibility.
We know this is not an ideal long-term solution, but it should help get you unblocked for now.

Best regards,
Steven


Steven Andrews
Sr. Director, Support Engineering
OptiTrack

[vsm]

Hi Steven,
Thank you for your answer.
In fact, this is not a very satisfiying solution, since all my code base is compiled with v143 toolchain, making heavy use of C++20 features which are perhaps not supported by the toolchain you compile MotiveAPI DLL with.
Furthermore, for this workaround to work, it would require my code to be compiled with/linked against exactly the same standard library version you're using, which is very hard (and quite impossible) to achieve.
For the moment, the only MotiveAPI function I use and that could lead to an issue is "MotiveAPI::CalibrationCamerasLackingSamples()" which returns an std::vector<int>.
I guess the std::vector<int> is allocated inside the MotiveAPI DLL. Could you ask your development team if they can think of a specific workaround for the usage of this very function?
Thank you.
Best regards,
Vincent

[JimmyMorris]

Excellent point — using STL types across module boundaries is definitely risky. I’ve run into similar ABI issues when mixing compilers or CRT settings. APIs should ideally use POD types or opaque handles to avoid this

[steven.andrews]

Hi Vincent,

Thank you again for following up and for explaining your setup in more detail. You make a very valid point regarding the challenges of matching compiler versions and standard libraries, especially when working with newer toolchains and C++20 features.

At this time, the Motive API’s interface and toolchain are tightly coupled with the current Motive build environment. Making significant structural changes to remove STL types from the API boundary would require a substantial rewrite of the existing interface layer, so this is unfortunately not something we can address in the near term.

That said, we are aware of these limitations and are exploring longer-term architectural changes that would give developers much more flexibility in how they integrate with Motive. Those changes are still a ways out, but they are being planned with exactly these kinds of concerns in mind.

For now, continuing to align your build configuration with the provided sample projects remains the best way to avoid ABI-related instability.

Thank you again for the thoughtful feedback and for taking the time to share your experience. It is genuinely helpful for us as we plan future improvements.

Best regards,
Steven


Steven Andrews
Sr. Director, Support Engineering
OptiTrack