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
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
