Intel C++ integration problem - Intel Parallel Studio XE for windows

[Fabien_D_1]

I'm an user of Intel products (Fortran / C++) since version 9.

I'm evaluating the new Intel Parallel Studio XE for windows. When installing, I made a full install. I had no visual studio installation before the install.

The problem is that I can't open or create C++ projects (vcproj) in visual studio 2008.
Although I have the C++ compiler correctly installed (I can start the compiler command prompt and compile C files with the icl command), I see no integration in the IDE (I can create and open fortran vfproj files).

Is this normal ? Is this a bug or is there something I can try to make it work ?

Thank you

[JenniferJ · Accepted solution]

If you do not have VS installed on the system, the VS from Intel Parallel Studio XE is the VS2008 shell.
Only the Intel Visual Fortran is integrated into the VS2008 shell. The Intel C++ is not.

If you need to use Intel C++ within VS, you do need to have the VS2008 standard edition or above.

Hope thismakes it clear for you now.

thanks,
Jennifer

[Fabien_D_1]

Hi,

Thank you for the information.

BUT

Now I'm trying to use the VS2008 shell to compile my C/C++ files.

Just for the sake of testing if the compiler works, I took a sample in the Samples folder, unzipped it, sourced the compiler variables then run the batch to compile.

The output impresses me: icl: error #10114: microsoft visual c++ not found in path

I can compile all my fortran programs from the command line in an analog way (ifort instead of icl) and it runs perfectly.

It seems that I can't use intel C compiler without a "real" version of ms visual studio. Is it true ?

thanks,
Fabio

[Om_S_Intel]

Yes. You need suitable Microsoft VS version as described in release notes to run Intel C++ compiler.

[Fabien_D_1]

Thank you very much.

The point is that I don't understand why we have a "package" for Fortran (I mean: an installer, IDE integration, shell to compile using command-line) and for C++ we have "nothing" (unless I install by myself a third-party application which risks imcompatibility with my fortran environment and even then I can't use the C++ IDE or build intel 64 apps).

To be more precise, we buy a whole package to make easy integrating C/Fortran and then we have to install other application to make it "work".

I'm in charge of taking technical decisions on the compiler side for my team. I like intel products, they're solid, I can use it in two OSes with no modification to the code but now I don't see an argument to buy the Intel version of the C++ compilers.

Thank you.

[Om_S_Intel]

This is licensing issue.

For limited use with Intel Fortran compiler Intelhas licencing agreementto bundle Microsoft tools and runtime support libraries. This is not the case for use with Intel C++ compiler. The customer need to buy the license from Microsoft himself.

[TimP]

To answer with a little more verbosity: the Fortran support package licensed by Microsoft for inclusion with Fortran sold by a few vendors adds $100 to the price of each sale, and has all C and C++ support stripped out, so it's useless for mixed C and Fortran development. Also, it has no relevance to those who are eligible for more attractive academic pricing from Microsoft. It took years of negotiation to reach agreement to support Fortran this way.

[Ravindra_R_]

Hi,
I am having a similar issue as detailed above, but need some further clarity from the experts please.
I do not have any Visual studio product installed but have the Intel compilers which I want to use to complile C/C++ source files directly from the command line on Windows...
I want to compile source files into portable executable code that is not dependant on th microsoft platform using the intel compilers. Reading the thread responses above and below, is it correct to assume that Visual Studio/C++ is a pre-requisite to do this? This then, defeats the purpose of portable code, because it not only means paying for two products but raises the question as to why buy the intel compilers for windows separately when one could just use the Visual Studio native complilers and; also needing Visual C++ means that my compiled product could not be that portable after all?
Any suggestions/comments please?

[mecej4]

> I want to compile source files into portable executable code that is not dependent on the microsoft platform using the intel compilers.

If by 'platform' you mean OS, system libraries and C/C++ tools and linkers, Intel C/C++ does not meet your requirements, because of restrictions that MS imposes on Intel as to the redistribution of licensed Visual Studio components.

If, on the other hand, the MS IDE is the only part that you do not wish to use, command line development is possible without having Visual Studio installed. You will still need to obtain from MS and install the 32 and 64-bit Windows SDK for your Windows version. Think of the Intel compilers as replacements for the Visual C/C++ compilers -- replacements that you may choose either for generating faster code or because they support language features that are unavailable in the MS compilers.

[TimP]

To hint that you want to build for Windows platform without dependence on Microsoft components seems contradictory (isn't Windows itself a Microsoft platform component?). MinGW goes further in this direction than you can with Intel and Microsoft development components, as it never links against Microsoft redistributable libraries, but MinGW is deficient in parallelism support (in my experience).

The purpose of Intel compiler tools for Windows is not to replace Microsoft Visual Studio or SDK components; it is to provide more performance (e.g. auto-vectorization, performance analysis, and run-time affinity tools) and to some extent more source code portability (e.g. useful partial C99 and OpenMP 3.1 support).

In default /MD mode with Microsoft or Intel compilers, you make a .exe which can run on any suitable version of Windows where you have installed the Microsoft and Intel redistributable libraries. By switching to /MT, you can avoid depending on the redistributables.