Microsoft* Compatibility

Microsoft Visual Studio Integration

The compiler is compatible with Microsoft Visual Studio 2017, 2019, and 2022 projects.

Unsupported Features

Unsupported project types:

.NET*-based CLR C++ project types are not supported by the Intel® oneAPI DPC++/C++ Compiler. The specific project types will vary depending on your version of Visual Studio, for example: CLR Class Library, CLR Console App, or CLR Empty Project.

Unsupported major features:

• COM Attributes

• C++ Accelerated Massive Parallelism (C++ AMP)

• Managed extensions for C++ (new pragmas, keywords, and command-line options)

• Event handling (new keywords)

• Select keywords:

  • __abstract
  • __box
  • __delegate
  • __gc
  • __identifier
  • __nogc
  • __pin
  • __property
  • __sealed
  • __try_cast
  • __w64

Unsupported preprocessor features:

• #import directive changes for attributed code

• #using directive

• managed, unmanaged pragmas

• _MANAGED macro

• runtime_checks pragma

Mixing Managed and Unmanaged Code

If you use the managed extensions to the C++ language in Microsoft Visual Studio .NET, you can use the compiler for your non-managed code for better application performance. Make sure managed keywords do not appear in your non-managed code.

For information on how to mix managed and unmanaged code, refer to the article, An Overview of Managed/Unmanaged Code Interoperability, on the Microsoft Web site.

Precompiled Header Support

There are some differences in how precompiled header (PCH) files are supported between the Intel® C++ Compiler Classic and the Microsoft* Visual C++* Compiler:

• The PCH information generated by the Intel® C++ Compiler Classic is not compatible with the PCH information generated by the Microsoft Visual Studio Compiler.

• The Intel® C++ Compiler Classic does not support PCH generation and use in the same translation unit.

• The Intel® C++ Compiler does not generate PCH information beyond a point where a declaration is seen in the primary translation unit. When the /Yu option is specified, the Microsoft* Visual C++* compiler ignores all text, including declarations preceding the #include statement of the specified file.

• The Microsoft* Visual C++* Compiler will not emit an error if a function or variable definition occurs in a PCH file which is included in two different source files and is not referenced. The Intel® C++ Compiler will always give a multiple definition link error under these circumstances.

Compilation and Execution Differences

While the Intel® C++ Compiler Classic is compatible with the Microsoft Visual C++* Compiler, some differences can prevent successful compilation. There can also be some incompatible generated-code behavior of some source files with the Intel® C++ Compiler Classic. In most cases, a modification of the user source file enables successful compilation with both the Intel® C++ Compiler Classic and the Microsoft Visual C++ Compiler. The differences between the compilers are:

• Evaluation of Left Shift Operations

  The Intel® C++ Compiler differs from the Microsoft Visual C++ Compiler in the evaluation of left shift operations where the right operand, or shift count, is equal to or greater than the size of the left operand expressed in bits. The ANSI C standard states that the behavior of such left-shift operations is undefined, meaning a program should not expect a certain behavior from these operations. This difference is only evident when both operands of the shift operation are constants. The following example illustrates this difference between the Intel® C++ Compiler and the Microsoft Visual C++ Compiler:

  int x; 
  int y = 1; //set y=1 
  void func() {
    x = 1 << 32;
    // Intel C++ Compiler generates code to set x=1
    // Visual C++ Compiler generates code to set x=0  
  
    y = y << 32;
    // Intel C++ Compiler generates code to set y=1 
    // Visual C++ Compiler generates code to set y=1
  }

• Inline Assembly Target Labels (IA-32 Architecture Only)

  For compilations targeted for IA-32 architecture, inline assembly target labels of goto statements are case sensitive. The Microsoft Visual C++ compiler treats these labels in a case insensitive manner. For example, the Intel® C++ Compiler Classic issues an error when compiling the following code:

  int func(int x) {
     goto LAB2;
       // error: label "LAB2" was referenced but not defined
     __asm lab2: mov x, 1
     return x;
  }

  However, the Microsoft Visual C++ Compiler accepts the preceding code. As a work-around for the Intel® C++ Compiler Classic, when a goto statement refers to a label defined in inline assembly, you must match the label reference with the label definition in both name and case.

• Inlining Functions Marked for dllimport

  The Intel® C++ Compiler Classic will attempt to inline any functions that are marked dllimport but Microsoft* will not. Therefore, any calls or variables used inside a dllimport routine need to be available at link time or the result will be an unresolved symbol.

  The following example contains two files: header.h and bug.cpp.

  header.h:

  #ifndef _HEADER_H
  #define _HEADER_H
  namespace Foo_NS { 
  
          class Foo2 { 
          public: 
                  Foo2(){}; 
                  ~Foo2(); 
                  static int test(int m_i); 
          }; 
  } 
  #endif

  bug.cpp:

  #include “header.h”
  struct Foo2 { 
    static void test(); 
  }; 
  
  struct __declspec(dllimport) Foo 
  { 
     void getI() { Foo2::test(); }; 
  }; 
  
  struct C  { 
    virtual void test(); 
  }; 
  
  void C::test() { Foo* p;  p->getI(); } 
  
  int main() { 
     return 0; 
  } 
  

Declaration in Scope of Function Defined in a Namespace

In accordance with the C++ language specification, if a function declaration is encountered within a function definition, the function referenced is taken to be another member of the namespace of the containing function; regardless of whether the containing function definition is lexically within a namespace definition. The Microsoft* Visual C++* compiler takes the referenced function to be a global function (not in any namespace).

Functions declared in global or namespace scopes are interpreted the same way by both the Intel® C++ Compiler and the Microsoft* Visual C++* compiler.

Enum Bit-Field Signedness

The Intel® C++ Compiler Classic and Microsoft* Visual C++* differ in how they attribute signedness to bit fields declared with an enum type. Microsoft Visual C++ always considers enum bit fields to be signed, even if not all values of the enum type can be represented by the bit field.

The Intel® C++ Compiler Classic considers an enum bit field to be unsigned, unless the enum type has at least one enum constant with a negative value. In any case, the Intel® C++ Compiler Classic produces a warning if the bit field is declared with too few bits to represent all the values of the enum type.