Microsoft Compatibility

Intel® C++ Compiler Classic Developer Guide and Reference

Download PDF

ID 767249

Date 12/16/2022

Version

Public

A newer version of this document is available. Customers should click here to go to the newest version.

Visible to Intel only — GUID: GUID-DE561D15-32BB-4A3E-999C-EF0BDB9E427C

View Details

Microsoft Compatibility

The Intel® C++ Compiler Classic is fully source- and binary-compatible (native code only) with Microsoft Visual C++ (MSVC). You can debug binaries built with the Intel® C++ Compiler Classic from within the Microsoft Visual Studio environment.

The compiler supports security checks with the /GS option. You can control this option in the Microsoft Visual Studio IDE by using C/C++ > Code Generation > Buffer Security Check.

The compiler also includes support for safe exception handling features with the /Qsafeseh option for 32-bit binaries. This option is on by default. You can control this option in the Microsoft Visual Studio IDE by using C/C++ > Command Line > Additional options.

IMPORTANT:

The compiler is a hosted compiler, not a standalone compiler. The compiler requires that standard development tools for the host system (linker, librarian, and so forth), and standard libraries and headers, are installed and available in your Path, Library Path, and Include environment variables. The host compiler provides access to I/O facilities through, for example, <stdio.h> and the C runtime library, as well as providing the implementation for the C++ standard template (for example, <vector>). When you build your application with the compiler, the stdio.h file is found in the host compiler's library. Likewise when you link your application, the link step uses the host OS linker to bind the application, and the host C runtime library provides the implementation for the runtime support routines.

On Windows, the standard compiler is Microsoft Visual C++. On Linux, the standard compiler is GCC. The standard compiler must be installed and available in your environment before you run the compiler.

Microsoft Visual Studio Integration

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

NOTE:

Support for Microsoft Visual Studio 2017 is deprecated as of the Intel® oneAPI 2022.1 release, and will be removed in a future release.

Unsupported Features

Unsupported project types:

.NET-based CLR C++ project types are not supported by the Intel® C++ Compiler Classic. The specific project types will vary depending on your version of Visual Studio, for example:
- CLR Class Library
- CLR Console App
- 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. This is 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.

Parent topic: Compatibility and Portability

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Intel® C++ Compiler Classic Developer Guide and Reference

Microsoft Compatibility

Microsoft Visual Studio Integration

Unsupported Features

Mixing Managed and Unmanaged Code

Precompiled Header Support

Compilation and Execution Differences

Declaration in Scope of Function Defined in a Namespace

Enum Bit-Field Signedness

See Also