openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Openexr-devel] OpenEXR Windows port


From: Luc-Eric Rousseau
Subject: RE: [Openexr-devel] OpenEXR Windows port
Date: Fri, 24 Jan 2003 10:42:50 -0500

> -----Original Message-----
> From: Dustin Graves [mailto:address@hidden]
>
> Last night I did a rough port to Windows with Visual Studio 6 + Intel
> 5.0 Compiler.  I was unable to use the compilers provided with both
> Visual Studio 6.0 and .NET because they do not recognize this
> as legal syntax:
>
> template <class T>
> template <class S>
> inline bool
> Vec2<T>::operator != (const Vec2<S> &v) const
> ...
> The template followed by a template causes a syntax error.  This is a
> bug with the compiler, which I'll try reporting to Microsoft.

try template <class T, class S>, should be the same
 
> But I was able to compile most of the code with the Intel compiler.
> Everything except IlmImfTest and ImathTest, because they use
> the drand48 family of functions which are not provided with Visual
> Studio.  The port was pretty simple, requiring few changes.  The
> most prominent changes were:
>
> 1.  typedef Int64 as __int64

non ansi types..

> 2.  the numeric suffix UUL is not supported, and must be changed to UL

> 3.  std::min and std::max are unavailable (due to conflict
> with min and
> max in windefs.h), so std::_MIN and std::_MAX are provided instead.

When you need to include windows.h, use #define NOMINMAX before
including it.  See windef.h.  you may also #define WIN32_LEAN_AND_MEAN
to speed up compile.

> 4.  Imath needed a preprocessor directive to indicate hypot should be
> used instead of hypotf

> 5.  Scoping error with variable declarations within 'for' loops,
> resulting in multiple defines, required variables to be
> declared outside
> of the 'for' loop, once per function.

I'm not too fond of the new scoping rule, but you can enable it in
VC++ 6.0 with "Disable language extensions", in the compiler settings.
It's off by default because it breaks existing code, in some cases
silently.

> 6.  windows.h must be included before gl.h

always a pain, with no specificly good work around other
than hidding it in a portability .h file.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]