In the MMDevice interface, we maintain binary compatibility between device adapters and MMCore built by different compilers and C++ runtimes (or their versions, and, importantly, MSVC Debug vs Release) by limiting ourselves to pure C data types (except for the device classes themselves, which are pure C plus C++ vtables, but that also has a very stable binary interface on each platform).
There is one last C++ class type that is passed between devices and the Core in violation of those rules: MMTime. (In fact, it caused an unintended binary compatibility breakage on Linux/Mac while it was being cleaned up from an earlier, even more problematic form.)
Now that the MMCore (CoreCallback) implementation of GetCurrentMMTime() simply calls std::chrono::steady_clock::now(), there is no longer a good reason for it to be in the Core. It would be the same if we just provide an implementation in CDeviceBase.
Note that steady_clock is consistent between standard library implementations on each platform, and even if it were not, device adapters do not (and should not) use MMTime for cross-adapter time calculations.
The MMTime type itself should be deprecated because std::chrono::steady_clock should be preferred (std::chrono timepoint/duration types are strictly superior to MMTime). But doing so would generate too many warnings. Perhaps we should conditionally deprecate it, so that we can turn off warnings in existing device adapters using a preprocessor macro. We could also move it out of the main MMDevice.h into a dedicated MMTime.h.
Device Interface Version needs to be bumped for final removal of MM::Core::GetCurrentMMTime(). Updating CDeviceBase::GetCurrentMMTime() (which currently wraps the former) to use a local implementation could be done without DIV bump, but probably best to do in a single step, just to avoid having two sources of time in the same DIV, even if identically coded. Devices rarely (if ever) directly call GetCoreCallback()->GetCurrentMMTime(), so removing that should be easy.
The very problematic (easily overflowing) GetClockTicksUs() could also be converted to an implementation that avoids calling into the Core, even though it doesn't pose any binary compatibility issues. It should be conditionally deprecated similarly to MMTime.
In the MMDevice interface, we maintain binary compatibility between device adapters and MMCore built by different compilers and C++ runtimes (or their versions, and, importantly, MSVC Debug vs Release) by limiting ourselves to pure C data types (except for the device classes themselves, which are pure C plus C++ vtables, but that also has a very stable binary interface on each platform).
There is one last C++ class type that is passed between devices and the Core in violation of those rules:
MMTime. (In fact, it caused an unintended binary compatibility breakage on Linux/Mac while it was being cleaned up from an earlier, even more problematic form.)Now that the MMCore (
CoreCallback) implementation ofGetCurrentMMTime()simply callsstd::chrono::steady_clock::now(), there is no longer a good reason for it to be in the Core. It would be the same if we just provide an implementation inCDeviceBase.Note that
steady_clockis consistent between standard library implementations on each platform, and even if it were not, device adapters do not (and should not) useMMTimefor cross-adapter time calculations.The
MMTimetype itself should be deprecated becausestd::chrono::steady_clockshould be preferred (std::chronotimepoint/duration types are strictly superior toMMTime). But doing so would generate too many warnings. Perhaps we should conditionally deprecate it, so that we can turn off warnings in existing device adapters using a preprocessor macro. We could also move it out of the mainMMDevice.hinto a dedicatedMMTime.h.Device Interface Version needs to be bumped for final removal of
MM::Core::GetCurrentMMTime(). UpdatingCDeviceBase::GetCurrentMMTime()(which currently wraps the former) to use a local implementation could be done without DIV bump, but probably best to do in a single step, just to avoid having two sources of time in the same DIV, even if identically coded. Devices rarely (if ever) directly callGetCoreCallback()->GetCurrentMMTime(), so removing that should be easy.The very problematic (easily overflowing)
GetClockTicksUs()could also be converted to an implementation that avoids calling into the Core, even though it doesn't pose any binary compatibility issues. It should be conditionally deprecated similarly toMMTime.