Extra #defines for Windows SDK 6.0a/VS2008

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Extra #defines for Windows SDK 6.0a/VS2008

per@lumai.se
Hi all,

here's a proposed patch for
clang/lib/Basic/Targets.cpp::VisualStudioWindowsX86_32TargetInfo that
adds three new defines. This allows <windows.h> pass clang compilation
both in C and C++. Comments?

--
Per Lindén

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

VisualStudioWindowsX86_32TargetInfo.patch (986 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Francois Pichet
I don't think WIN32_LEAN_AND_MEAN should be predefined in clang
because it is not a predefined macro. It is generally defined in
stdafx.h and some projects actually need to compile without
WIN32_LEAN_AND_MEAN. If you need it use -DWIN32_LEAN_AND_MEAN.


On Thu, Aug 5, 2010 at 8:58 AM, [hidden email] <[hidden email]> wrote:

> Hi all,
>
> here's a proposed patch for
> clang/lib/Basic/Targets.cpp::VisualStudioWindowsX86_32TargetInfo that adds
> three new defines. This allows <windows.h> pass clang compilation both in C
> and C++. Comments?
>
> --
> Per Lindén
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

per@lumai.se
Francois Pichet skrev 2010-08-05 17:33:
> use it is not a predefined macro. It is generally defined in
> stdafx.h and some projects actually need to compile wit

Yeah, I was not sure about whether that one was a good idea. The thing
is that it's the simplest fix I found to stop that IID_PPV_ARGS_Helper
mess from breaking builds in C++ mode without editing the SDK files. The
best thing would of course be non-broken headers from M$... The other
two defines would be OK, right?

My goal is to get libcxx through clang in the MSVC environment and it
uses sockets which of course pull in windows.h, as everything else
does... The dependence on non-MS-supported C99 library functions in
libcxx are yet another issue to work around...

--
Per Lindén

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Jesse Towner
Yeah, Windows.h sure brings in a lot of dependencies, no one will deny that. One thing I've seen done on some projects before that needed to pull in some declaration from Windows.h into project headers without polluting the global namespace is to redeclare them nested inside of a private namespace.

Example:

// some_project/threading/windows/mutex.hpp

namespace some_project
{
   namespace detail
   {
       namespace windows
       {
#pragma pack(push, 8)
           struct CRITICAL_SECTION
           {
               void* debug_info;
               long lock_count;
               long recursion_count;
               void* owning_thread;
               void* lock_semaphore;
               uintptr_t spin_count;
           };
#pragma pack(pop)

           extern "C" __declspec(dllimport) int __stdcall InitializeCriticalSectionEx(CRITICAL_SECTION*, unsigned long, unsigned long);
           extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION*);
           extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION*);
           extern "C" __declspec(dllimport) unsigned long __stdcall SetCriticalSectionSpinCount(CRITICAL_SECTION*, unsigned long);
           extern "C" __declspec(dllimport) int __stdcall TryEnterCriticalSection(CRITICAL_SECTION*);
           extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION*);
           // etc.
       }
   }

   // ...
   // use it
  
   class mutex
   {
   public:

       // ...

       void lock() {
           detail::windows::EnterCriticalSection(&mutex_);
       }

   private:

       detail::windows::CRITICAL_SECTION mutex_;
   };
}

Of course, the problem with this is you suddenly need to maintain all of these prototypes and type definition and make sure they match up with the Windows ABI, and you need to do it for multiple target architectures. Fortunately, Windows is fairly stable in this regard, so once you do get it working, you usually don't need to look at it again. Another good thing is that it doesn't necessarily interfere later on when you do include Windows.h in an actual translation unit. I'm not sure if something like this might be helpful. Just an idea.

- Jesse Towner

On Thu, Aug 5, 2010 at 8:43 AM, [hidden email] <[hidden email]> wrote:
> Francois Pichet skrev 2010-08-05 17:33:
>> use it is not a predefined macro. It is generally defined in
>> stdafx.h and some projects actually need to compile wit
>
> Yeah, I was not sure about whether that one was a good idea. The thing
> is that it's the simplest fix I found to stop that IID_PPV_ARGS_Helper
> mess from breaking builds in C++ mode without editing the SDK files. The
> best thing would of course be non-broken headers from M$... The other
> two defines would be OK, right?
>
> My goal is to get libcxx through clang in the MSVC environment and it
> uses sockets which of course pull in windows.h, as everything else
> does... The dependence on non-MS-supported C99 library functions in
> libcxx are yet another issue to work around...
>
> --
> Per Lindén
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

per@lumai.se
Of course there are numerous workarounds. My primary goal is to make it
easier to use clang on existing (Windows) code bases. It should "just
work" as far as possible. Otherwise, what's the point of
TargetInfo::getTargetDefines?

Any comments on the actual patch? Perhaps I should file a bug instead?

--
Per Lindén

Jesse Towner skrev 2010-08-05 18:12:

> Yeah, Windows.h sure brings in a lot of dependencies, no one will deny
> that.. One thing I've seen done on some projects before that needed to
> pull in some declaration from Windows.h into project headers without
> polluting the global namespace is to redeclare them nested inside of a
> private namespace.
>
> Example:
>
> // some_project/threading/windows/mutex.hpp
>
> namespace some_project
> {
>     namespace detail
>     {
>         namespace windows
>         {
> #pragma pack(push, 8)
>             struct CRITICAL_SECTION
>             {
>                 void* debug_info;
>                 long lock_count;
>                 long recursion_count;
>                 void* owning_thread;
>                 void* lock_semaphore;
>                 uintptr_t spin_count;
>             };
> #pragma pack(pop)
>
>             extern "C" __declspec(dllimport) int __stdcall
> InitializeCriticalSectionEx(CRITICAL_SECTION*, unsigned long, unsigned
> long);
>             extern "C" __declspec(dllimport) void __stdcall
> EnterCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) void __stdcall
> LeaveCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) unsigned long __stdcall
> SetCriticalSectionSpinCount(CRITICAL_SECTION*, unsigned long);
>             extern "C" __declspec(dllimport) int __stdcall
> TryEnterCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) void __stdcall
> DeleteCriticalSection(CRITICAL_SECTION*);
>             // etc.
>         }
>     }
>
>     // ...
>     // use it
>
>     class mutex
>     {
>     public:
>
>         // ...
>
>         void lock() {
>             detail::windows::EnterCriticalSection(&mutex_);
>         }
>
>     private:
>
>         detail::windows::CRITICAL_SECTION mutex_;
>     };
> }
>
> Of course, the problem with this is you suddenly need to maintain all of
> these prototypes and type definition and make sure they match up with
> the Windows ABI, and you need to do it for multiple target
> architectures. Fortunately, Windows is fairly stable in this regard, so
> once you do get it working, you usually don't need to look at it again.
> Another good thing is that it doesn't necessarily interfere later on
> when you do include Windows.h in an actual translation unit. I'm not
> sure if something like this might be helpful. Just an idea.
>
> - Jesse Towner
>
> On Thu, Aug 5, 2010 at 8:43 AM, [hidden email]
> <mailto:[hidden email]> <[hidden email]
> <mailto:[hidden email]>> wrote:
>  > Francois Pichet skrev 2010-08-05 17:33:
>  >> use it is not a predefined macro. It is generally defined in
>  >> stdafx.h and some projects actually need to compile wit
>  >
>  > Yeah, I was not sure about whether that one was a good idea. The thing
>  > is that it's the simplest fix I found to stop that IID_PPV_ARGS_Helper
>  > mess from breaking builds in C++ mode without editing the SDK files. The
>  > best thing would of course be non-broken headers from M$... The other
>  > two defines would be OK, right?
>  >
>  > My goal is to get libcxx through clang in the MSVC environment and it
>  > uses sockets which of course pull in windows.h, as everything else
>  > does... The dependence on non-MS-supported C99 library functions in
>  > libcxx are yet another issue to work around...
>  >
>  > --
>  > Per Lindén

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor
In reply to this post by per@lumai.se

On Aug 5, 2010, at 2:58 PM, [hidden email] wrote:

> Hi all,
>
> here's a proposed patch for clang/lib/Basic/Targets.cpp::VisualStudioWindowsX86_32TargetInfo that adds three new defines. This allows <windows.h> pass clang compilation both in C and C++. Comments?

Does the Visual Studio compiler actually define all of these macros? We shouldn't be defining any macros just to make things seem to work (e.g., we can't define WIN32_LEAN_AND_MEAN by default). Rather, we should define the same macros that Visual Studio does and, if necessary, we should implement more Microsoft-specific extensions (or even bugs) under -fms-extensions.

_INTEGRAL_MAX_BITS makes sense to define, because it's documented to be defined by Visual Studio.

__STDC__ should probably only be defined in C mode when -pedantic is specified or we're not in Microsoft mode. The logic in InitPreprocessor.cpp could use some tweaking.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

per@lumai.se
Great, I'm all for setting _INTEGRAL_MAX_BITS. It is defined by the MSVC
compiler. All the mentioned defines are described at
http://msdn.microsoft.com/en-us/library/b0084kay%28VS.80%29.aspx
The code (<oaidl.h>) that is fixed by __STDC__ resembles

#if !__STDC__ && (_MSC_VER <= 1000)
        /* Create a struct with a member named "bool" = non-C++ */
#else
        /* Don't create the offending struct */
#endif

, so to remedy this either __STDC__ must be defined or _MSC_VER must be
set to some value such as "1100" which might be weird since it implies
the presence of the MSVC compiler.

As the page above states, __STDC__ = "Indicates full conformance with
the ANSI C standard" which is the Microsoft definition of C. My guess is
that it is _much_ less standardized than clang -strict would imply?

The problem is that this is plainly broken code in the SDK. I would not
suggest allowing "bool" as an identifier even under ms-extensions ;-)

Fiddling with these things is boring but allowing clang to work as a
drop-in replacement on a wider existing Windows code base would be a
good thing, at least in my mind.

Btw, how do I invoke the Windows COFF writer? Got lost in the options...

--
Per Lindén

Douglas Gregor skrev 2010-08-06 10:43:

>
> On Aug 5, 2010, at 2:58 PM, [hidden email] wrote:
>
>> Hi all,
>>
>> here's a proposed patch for clang/lib/Basic/Targets.cpp::VisualStudioWindowsX86_32TargetInfo that adds three new defines. This allows<windows.h>  pass clang compilation both in C and C++. Comments?
>
> Does the Visual Studio compiler actually define all of these macros? We shouldn't be defining any macros just to make things seem to work (e.g., we can't define WIN32_LEAN_AND_MEAN by default). Rather, we should define the same macros that Visual Studio does and, if necessary, we should implement more Microsoft-specific extensions (or even bugs) under -fms-extensions.
>
> _INTEGRAL_MAX_BITS makes sense to define, because it's documented to be defined by Visual Studio.
>
> __STDC__ should probably only be defined in C mode when -pedantic is specified or we're not in Microsoft mode. The logic in InitPreprocessor.cpp could use some tweaking.
>
> - Doug


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor

On Aug 6, 2010, at 12:02 PM, [hidden email] wrote:

> Great, I'm all for setting _INTEGRAL_MAX_BITS. It is defined by the MSVC
> compiler.

I've committed that change in Clang r110442.

> All the mentioned defines are described at
> http://msdn.microsoft.com/en-us/library/b0084kay%28VS.80%29.aspx
> The code (<oaidl.h>) that is fixed by __STDC__ resembles
>
> #if !__STDC__ && (_MSC_VER <= 1000)
> /* Create a struct with a member named "bool" = non-C++ */
> #else
> /* Don't create the offending struct */
> #endif
>
> , so to remedy this either __STDC__ must be defined or _MSC_VER must be
> set to some value such as "1100" which might be weird since it implies
> the presence of the MSVC compiler.
>
> As the page above states, __STDC__ = "Indicates full conformance with
> the ANSI C standard" which is the Microsoft definition of C. My guess is
> that it is _much_ less standardized than clang -strict would imply?

Unfortunately, they only define __STDC__ for C, and we're likely to break something entirely different if we define it for C++.

> The problem is that this is plainly broken code in the SDK. I would not
> suggest allowing "bool" as an identifier even under ms-extensions ;-)
>
> Fiddling with these things is boring but allowing clang to work as a
> drop-in replacement on a wider existing Windows code base would be a
> good thing, at least in my mind.

I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor
In reply to this post by per@lumai.se

On Aug 6, 2010, at 12:02 PM, [hidden email] wrote:

> Great, I'm all for setting _INTEGRAL_MAX_BITS. It is defined by the MSVC
> compiler.

I've committed that change in Clang r110442.

> All the mentioned defines are described at
> http://msdn.microsoft.com/en-us/library/b0084kay%28VS.80%29.aspx
> The code (<oaidl.h>) that is fixed by __STDC__ resembles
>
> #if !__STDC__ && (_MSC_VER <= 1000)
> /* Create a struct with a member named "bool" = non-C++ */
> #else
> /* Don't create the offending struct */
> #endif
>
> , so to remedy this either __STDC__ must be defined or _MSC_VER must be
> set to some value such as "1100" which might be weird since it implies
> the presence of the MSVC compiler.
>
> As the page above states, __STDC__ = "Indicates full conformance with
> the ANSI C standard" which is the Microsoft definition of C. My guess is
> that it is _much_ less standardized than clang -strict would imply?

Unfortunately, they only define __STDC__ for C, and we're likely to break something entirely different if we define it for C++.

> The problem is that this is plainly broken code in the SDK. I would not
> suggest allowing "bool" as an identifier even under ms-extensions ;-)
>
> Fiddling with these things is boring but allowing clang to work as a
> drop-in replacement on a wider existing Windows code base would be a
> good thing, at least in my mind.

I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

David Chisnall
In reply to this post by Douglas Gregor
On 6 Aug 2010, at 14:21, Douglas Gregor wrote:

>> Fiddling with these things is boring but allowing clang to work as a
>> drop-in replacement on a wider existing Windows code base would be a
>> good thing, at least in my mind.
>
> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?

We already define the GCC version macros so that we can act as a drop-in replacement for GCC.  If we're aiming to act as a drop-in replacement for MSVC then it would make sense to define their version macros and treat any incompatibilities in MS-extensions mode as bugs, just as we treat incompatibilities with GCC in GNU C modes as bugs.  

David

-- Send from my Jacquard Loom


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Anton Korobeynikov
In reply to this post by Douglas Gregor
> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
mingw does not define _MSC_VER. Basically, _MSC_VER define is a
standard way of detection of VCPP (like __GNUC__ for gcc).

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Jesse Towner
In reply to this post by Douglas Gregor
On Fri, 2010-08-06 at 15:24 +0200, Douglas Gregor wrote:

> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
>

I recently replied to Per on this, but forgot to CC it to the list, so
I'll provide the relevant stuff here.

MinGW has it's own version of the Platform SDK headers
in /include/w32api, and unfortunately it has a hard time working with
with the latest Platform SDK, DirectX SDK, or other SDK releases from
Microsoft until someone ports it to work with MinGW. I think Cygwin is
the same.

Intel C++ mimics MSVC++ to the extent that it defines _MSC_VER and
supports the same compiler extensions, and developers accustomed to
checking for __INTEL_COMPILER/__ICL before _MSC_VER to differentiate
between the two. That way it acts as a drop-in replacement for MSVC++.
And naturally, ICC also mimics GCC on Linux.

Borland C++ came with it's own copy of the Platform SDK headers, but I
think in it's later days it became compatible with MSVC++ in the same
way that Intel C++ is. I'm not 100% sure though.

- Jesse Towner

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Bjorn Reese
In reply to this post by David Chisnall
On 2010-08-06 15:45, David Chisnall wrote:
> On 6 Aug 2010, at 14:21, Douglas Gregor wrote:
>
>> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
>
> We already define the GCC version macros so that we can act as a drop-in replacement for GCC.  If we're aiming to act as a drop-in replacement for MSVC then it would make sense to define their version macros and treat any incompatibilities in MS-extensions mode as bugs, just as we treat incompatibilities with GCC in GNU C modes as bugs.

Defining _MSC_VER or __GNUC__ or any other macro that identifies another
compiler is a problem because it makes it very difficult to handle
differences or defects via predefined macros.

Many projects rely on this, e.g. boost, wxwidget, and indeed your own
libcxx.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor

On Aug 6, 2010, at 4:19 PM, Bjorn Reese wrote:

> On 2010-08-06 15:45, David Chisnall wrote:
>> On 6 Aug 2010, at 14:21, Douglas Gregor wrote:
>>
>>> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
>>
>> We already define the GCC version macros so that we can act as a drop-in replacement for GCC.  If we're aiming to act as a drop-in replacement for MSVC then it would make sense to define their version macros and treat any incompatibilities in MS-extensions mode as bugs, just as we treat incompatibilities with GCC in GNU C modes as bugs.
>
> Defining _MSC_VER or __GNUC__ or any other macro that identifies another
> compiler is a problem because it makes it very difficult to handle
> differences or defects via predefined macros.

... and not defining predefined macros makes it very difficult to handle code written for the dominant compiler on a platform. We're completely broken on Mac and Linux systems if we don't pretend to be GCC, and it appears that we'll have the same issue with MSVC on Windows.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Jesse Towner
In reply to this post by Bjorn Reese
You could still identify the compiler if you check for __clang__ before
__GNUC__ or _MSC_VER.

#if defined(__clang__)
// ... clang specific
#elif defined(_MSC_VER)
// ... MSVC++ specific
#endif

#ifdef _MSC_VER
// ... clang and MSVC++ compatible stuff
#endif

This is how it's done for Intel C++, just substitute __ICL in for
__clang__.

On Fri, 2010-08-06 at 16:19 +0200, Bjorn Reese wrote:

> On 2010-08-06 15:45, David Chisnall wrote:
> > On 6 Aug 2010, at 14:21, Douglas Gregor wrote:
> >
> >> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
> >
> > We already define the GCC version macros so that we can act as a drop-in replacement for GCC.  If we're aiming to act as a drop-in replacement for MSVC then it would make sense to define their version macros and treat any incompatibilities in MS-extensions mode as bugs, just as we treat incompatibilities with GCC in GNU C modes as bugs.
>
> Defining _MSC_VER or __GNUC__ or any other macro that identifies another
> compiler is a problem because it makes it very difficult to handle
> differences or defects via predefined macros.
>
> Many projects rely on this, e.g. boost, wxwidget, and indeed your own
> libcxx.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor
In reply to this post by Jesse Towner

On Aug 6, 2010, at 4:00 PM, Jesse Towner wrote:

> On Fri, 2010-08-06 at 15:24 +0200, Douglas Gregor wrote:
>
>> I wonder how much will break if we start defining _MSC_VER? Does anyone know how mingw deals with this?
>>
>
> I recently replied to Per on this, but forgot to CC it to the list, so
> I'll provide the relevant stuff here.
>
> MinGW has it's own version of the Platform SDK headers
> in /include/w32api, and unfortunately it has a hard time working with
> with the latest Platform SDK, DirectX SDK, or other SDK releases from
> Microsoft until someone ports it to work with MinGW. I think Cygwin is
> the same.
>
> Intel C++ mimics MSVC++ to the extent that it defines _MSC_VER and
> supports the same compiler extensions, and developers accustomed to
> checking for __INTEL_COMPILER/__ICL before _MSC_VER to differentiate
> between the two. That way it acts as a drop-in replacement for MSVC++.
> And naturally, ICC also mimics GCC on Linux.
>
> Borland C++ came with it's own copy of the Platform SDK headers, but I
> think in it's later days it became compatible with MSVC++ in the same
> way that Intel C++ is. I'm not 100% sure though.

Okay, let's go for it. I don't have access to Visual Studio, so I'm asking for people with access to this compiler to provide patches. I strongly suggest going through the predefined macros documented here:

        http://msdn.microsoft.com/en-us/library/b0084kay.aspx

and making sure that, when we're in Microsoft mode (something that we may need to add, beyond just -fms-extensions), we define all of the same things they do. For example, _CPPRTTI when RTTI is enabled. Just adding _MSC_VER is only a partial solution that isn't likely to help all that much in isolation.

Which version of Visual C++ do we emulate? I'm guessing Visual Studio 2008 (_MSC_VER = 1500), since VS2010 has C++0x features that we don't support.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Dallman, John-3
> Which version of Visual C++ do we emulate? I'm guessing Visual Studio
> 2008 (_MSC_VER = 1500), since VS2010 has C++0x features that we don't
> support.

"That aren't supported as yet". The really thorough way of doing this
would
be to have an option for which Visual C++ to emulate. There's plenty of
stuff in MS headers that distinguishes between different versions, and
being capable of emulating more than one, while a counsel of perfection,
would make things easier for end-users.

--
John Dallman

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Douglas Gregor

On Aug 6, 2010, at 4:55 PM, Dallman, John wrote:

>> Which version of Visual C++ do we emulate? I'm guessing Visual Studio
>> 2008 (_MSC_VER = 1500), since VS2010 has C++0x features that we don't
>> support.
>
> "That aren't supported as yet". The really thorough way of doing this
> would
> be to have an option for which Visual C++ to emulate. There's plenty of
> stuff in MS headers that distinguishes between different versions, and
> being capable of emulating more than one, while a counsel of perfection,
> would make things easier for end-users.

Yes. I'd be open to reviewing/committing patches leading us in this direction, e.g.,

        -fmicrosoft=9.0

to try to emulate VC++ 9.0. However, someone else will have to take the lead on Microsoft compatibility.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

per@lumai.se
In reply to this post by per@lumai.se
The sad thing is that socket and thread support needed by libc++
indirectly cause inclusion of <windows.h>, at least as far as I can see
right now. Might be worked around by creating custom declarations of the
stuff needed but it usually spans 50 files... Also, all C99 standard lib
stuff must be replicated somehow. Et cetera... (does anyone feel
responsible for http://wiki.llvm.org/WinC99CLib:Windows_C99_clib ?)

There are of course other problems than MS extensions in the SDK
headers, such as template abuse, redefinition of "__null" etc. The
extension stuff implemented in clang so far works fairly well, with the
exception of some "throw(...)" exception specifications I am
investigating. In short <windows.h> really sucks, but finding
non-trivial Windows code that does not pull it in is hard. The question
is how to solve it without becoming incompatible, violating copyrights
etc. I volunteer to test and implement different solutions whenever I
get the time.

Thank you all for engaging in such a hopeless platform.
--
Per Lindén

Jesse Towner skrev 2010-08-06 14:04:

> Sorry, I missed what you originally wrote where you implied that you
> couldn't get a translation unit including Windows.h to even compile.
> Yeah, that's definitely a problem. I was thinking more along the lines
> of having Windows.h included by the libc++ headers, which might not be
> the wisest thing to force on the users of a standard library
> implementation.
>
> As far as how other compilers solve it, Intel C++ mimics MSVC++ to the
> extent that it defines _MSC_VER and supports the same compiler
> extensions, and library writers are accustomed to checking for
> __INTEL_COMPILER/ICL before _MSC_VER to differentiate between the two
> compilers. That way it acts as a drop-in replacement for MSVC++. Borland
> C++ came with it's own copy of the Platform SDK headers. And you
> probably know that Cygwin and MinGW also both come with their own copies
> of the headers. So the question is which route should Clang take here?
>
> - Jesse Towner
>
> On Fri, 2010-08-06 at 10:16 +0200, [hidden email] wrote:
>    
>> Of course there are numerous workarounds. My primary goal is to make it
>> easier to use clang on existing (Windows) code bases. It should "just
>> work" as far as possible. Otherwise, what's the point of
>> TargetInfo::getTargetDefines?
>>
>> Any comments on the actual patch? Perhaps I should file a bug instead?
>>
>>      
>    

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Extra #defines for Windows SDK 6.0a/VS2008

Dallman, John-3
In reply to this post by Douglas Gregor
Gregor [mailto:[hidden email]] wrote;

> Yes. I'd be open to reviewing/committing patches leading us in this
> direction, e.g.,
>
> -fmicrosoft=9.0
>
> to try to emulate VC++ 9.0.

Better to make it -fmicrosoft_version=15.0

This is because of history; there have been several separate MS
C/C++ compilers, and at least one reset of the marketing version
number, at "Visual C++ 1.0" when an existing compiler that had
several versions was bundled with a new IDE. The version number
sequence for the actual compiler has progressed smoothly for
about 20 years now, and is probably worth sticking with.

Incidentally, there's an undocumented option, /Bv, on the MS
compiler that produces a full and proper account of the version
numbers of the compiler and its components. This is handy when
trying to sort out details of differences between versions

http://www.geoffchappell.com/viewer.htm?doc=studies/msvc/cl/cl/options/b
$v.htm&tx=1&ts=0,78

best,

--
John Dallman


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
12