Hi Ger,
thank you for your ImathPlatform.h fixes. I did not apply of your
patches, but I believe I have addressed the issues you have pointed out:
* M_PI_2 and other M_* constantes are not defined in math.h on Windows:
I applied the part of your patch that defines M_PI_2, but I omitted M_E,
M_LOG2E etc. Those constants are not used anywhere in the OpenEXR code
base. Fixing broken math.h header files beyond what is necessary to
make OpenEXR compile is outside the scope of the OpenEXR project.
* restrict keyword: I replaced all instances of restrict in Imath with
IMATH_RESTRICT. ImathPlatform.h now defines IMATH_RESTRICT as __restrict
for GCC and VisualC++, restrict for Intel's and SGI's compilers, and as
an empty string for all other compilers.
Updated versions of ImathPlatform.h and ImathMatrix.h have been checked
into CVS.
Florian
Ger Hobbelt wrote:
Here's the addition of 'restrict' support for MSVC(2005 at least), as
that compiler also supports 'restrict', but there's a cinch. Which is
taken care of in this fix, though in a rather 'hackish' way. I've a
few other possbile slutions, but nothing else worked out. See the
comment in the diff/source code below.
Passes all OpenEXR tests on Win32 (compiled with MSVC2005SP1 on XP
32-bit, running on AMD XP (no! SSE2 support, so the project files are
tweaked; no other change for that). Will test on 64-bit Win platforms
later on, when I've migrated the project files.
diff included below (note that line numbers will be off, due to
M_PI/M_PI_2 fix up there in the same file).
Ger
--- \\Debbie\ger\prj\1original\OpenEXR\src\IlmBase\Imath\ImathPlatform.h
2006-12-09
00:23:08.000000000 +-0200
+++ \\Debbie\ger\prj\3actual\OpenEXR\IlmBase\Imath\ImathPlatform.h
2008-06-17
22:15:23.000000000 +-0200
@@ -81,12 +159,70 @@
#elif defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC)
|| defined(__ECC)
// supports restrict, do nothing.
#elif defined __sgi
// supports restrict, do nothing.
+#elif defined _MSC_VER
+ // supports restrict as __restrict.
+ //
+ // Unfortunately MSVC also knows 'restrict' in this context:
+ // __declspec(restrict)
+ // which leads to very 'funny' (not!) error reports in stdlib.h when it
is
+ // loaded AFTER this. And it often is... Sigh.
+ //
+ // So we do the hack thing and load <stdlib.h> anyway here, so the
preprocessor
+ // will prevent it from loading again after we coerce 'restrict' to
something
+ // meaningful for this compiler, e.g. '__restrict'.
+ //
+ // Update for the above:
+ //
+ // Microsoft encapsulates the 'restrict' in the define '_CRTRESTRICT',
+ // (Code based on the crtdefs.h definitions by Microsoft.)
+ // There are multiple system header files using this macro and we don't
want
+ // them to load here all, but we have to if we don't want the compiler
to barf
+ // as there's no simple way to use '__declspec(restrict)' in code
following this
+ // section where 'restict' is defined as '__restrict'.
+ // 'Best' (yech) thing I can think of now is #undef restrict at those
spots
+ // where you want to use __declspec(restrict) yourself. :-((
+ //
+ #if (defined(_M_IA64) && (_MSC_FULL_VER >= 13102050)) || (_MSC_VER >=
1400)
+ /* these compiler versions have __declspec(restrict); load the
header files which are affected */
+ #include <stdlib.h>
+ #include <malloc.h>
+ #endif
+
+ #if !defined(restrict)
+ /*
+ Microsoft says:
+
+ Like the restrict __declspec modifier, the __restrict
keyword
indicates that
+ a symbol is not aliased in the current scope. The
__restrict
keyword differs
+ from the restrict __declspec modifier in the following
ways:
+
+ - The __restrict keyword is valid only on variables, and
__declspec(restrict)
+ is only valid on function declarations and
definitions.
+
+ - When __restrict is used, the compiler will not
propagate the no-alias
+ property of a variable. That is, if you assign a
__restrict variable to
+ a non-__restrict variable, the compiler will not
imply that the
+ non-__restrict variable is not aliased.
+
+ Generally, if you affect the behavior of an entire
function, it is
better to
+ use the __declspec than the keyword.
+
+ __restrict is similar to restrict from the C99 spec,
but __restrict can be
+ used in C++ or C programs.
+
+ ----
+
+ Given the use of 'restrict' in OpenEXR, it should be
defined as
'__restrict'.
+ */
+ #define restrict __restrict
+ #endif
+
#else
#define restrict
#endif
#endif // INCLUDED_IMATHPLATFORM_H
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
