Development Reference Guides

Contents

Microsoft* Compatibility

This content is specific to C++; it does not apply to
DPC++
.
The
Intel® oneAPI
DPC++/C++
Compiler
is fully source- and binary-compatible (native code only) with Microsoft Visual C++* (MSVC). You can debug binaries built with the
Intel oneAPI
DPC++/C++
Compiler
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
.

Microsoft Visual Studio Integration

The compiler is compatible with Microsoft Visual Studio 2017, 2019, and 2022 projects.
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® 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® oneAPI
DPC++/C++
Compiler
and the Microsoft* Visual C++* Compiler:
  • The PCH information generated by the
    Intel oneAPI
    DPC++/C++
    Compiler
    is not compatible with the PCH information generated by the Microsoft Visual Studio Compiler.
  • The
    Intel oneAPI
    DPC++/C++
    Compiler
    does not support PCH generation and use in the same translation unit.

Compilation and Execution Differences

While the
Intel® oneAPI
DPC++/C++
Compiler
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 oneAPI
DPC++/C++
Compiler
. In most cases, a modification of the user source file enables successful compilation with both the
Intel oneAPI
DPC++/C++
Compiler
and the Microsoft Visual C++ Compiler. The differences between the compilers are:
  • Inline Assembly Target Labels (IA-32 Architecture Only)
    This content is specific to C++; it does not apply to
    DPC++
    .
    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 oneAPI
    DPC++/C++
    Compiler
    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 oneAPI
    DPC++/C++
    Compiler
    , 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 oneAPI
    DPC++/C++
    Compiler
    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; }

Enum Bit-Field Signedness

The
Intel® oneAPI
DPC++/C++
Compiler
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 oneAPI
DPC++/C++
Compiler
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 oneAPI
DPC++/C++
Compiler
produces a warning if the bit field is declared with too few bits to represent all the values of the
enum
type.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.