-
Notifications
You must be signed in to change notification settings - Fork 249
Description
I've discovered that the #defines in sal.h (included by DirectXMath.h) cause compilation issues with GCC utility headers (conflicting names in some std::move declarations, etc.).
Fortunately, this can be avoided by including the GCC headers before DirectXMath.h, but it's worth noting as it is not terribly obvious/easy to track down when you get compile errors by simply including utility.
To facilitate this, I've created by own wrapper include for DirectXMath, in which I explicitly include the problematic headers beforehand (as well as turn off various GCC warnings). eg:
#include <algorithm>
#include <utility>
#include "DirectXMath.h"
Thus far algorithm and utility have been the only two issues, but it's entirely conceivable there are other landmines yet to be stepped on.
I'm not sure there's a great solution for this aside from what I've done. Ideally it would be nice to eliminate having to hunt down the open-source sal.h by eliminating that requirement for non-Windows builds. However, I realize that presents a bit of a code explosion unless you were to add a level of indirection for all those SAL macros/defines...have DirectXMath macros for everything you use in the library, which on Windows resolve to the SAL macros, and on other platforms resolve to nothing.