I could perhaps guess as to why you did away with the version numbers in
rsi.h, but I’d rather hear the authoritative wisdom behind the decision.
Do you expect the header and ABI to change so little in the future, that informing clients at compile time is now no longer useful (for checking).
Up until now, I’ve (almost) insisted on running against the RMP version I compiled against—mostly because I don’t know which version milestones have ABI incompatibilities. Usually when there’s a mismatch, some attempt to do something causes a serious crash (in my experience, either my app or the RTA will crash).
With the exception of major revisions, we try to maintain binary compatibility. I would say that in general if you can compile against a particular version of RapidCode, things should just work.
That said, mismatched versions of RapidCode and the RMP (firmware) are likely to fail subtly (and sometimes not so subtly) so we fail the motion controller creation when this happens.
We originally got rid of the macros partially out of frustration with other API’s macro pollution, to streamline our versioning workflow, and the assumption that the ABI compatibility would in fact hold.
What functions/functionality were you using that caused the issues? And between which versions?
After a bit of discussion, we appreciate the version checking and are considering bringing it back.
I can’t say which API’s brought my app to its knees. I was using dozens of them, all more or less at the same time. I’m not trying to report an issue, only mentioning that when there were mismatches, I would sometimes see pretty serious crashes; so, we have historically tried to ensure that there were no mismatches (in superficial version numbers). It’s entirely likely that it had to do with firmware vs. client-side runtime code, but I can’t really say with any certainty. When I was looking into the crashes, as soon as I saw that my application was built against a different runtime, I resolved that problem first, and the crashing stopped happening.
If you’re considering reinstating CPP macros with version info, could I suggest that you also add some integer macros to that I can do actual compile-time comparisons and issue compiler errors or warnings? It’s nearly impossible (c++17) to compare strings with constexpr compile-time code, but it works fine with integers.
I’d be happy enough if the CPP macros were only integers (it’s always easy to convert an int to a string in a CPP macro, but the reverse is impossible), but you know what’s best.