I am working on VS2010 mixed-programing and use the Intel Compiler / VisualStudio (Intel Parallel 2015) to compile my project in VS 2010.
My program is compiling on Linux but not compiling in windows(VS) I don't know what happen exactly. Thanks
You might want to re-post your question on the Fortran forum. Here is one post that I found which discusses calling Fortran from C: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/515579
Your screenshot is showing a runtime error, not a compile time error.
When you run in the VS debugger, the default working directory is the Project directory of the executable (startup project). I suspect your data file is not located in the expected directory.
Also, it is not good practice to name your data file xxx.for
.for files are fixed format Fortran files.
I didn't check closely the code in this post, but it looks eerily familiar. How's the issue at hand different from those in the previous threads by this OP for which RO and mecej4 have provided detailed assistance as well as working code?
Apart from that, the OP is not using the correct invocation for the Fortran subroutine: in Fortran there is a hidden argument for character arguments which passes the length of the character variable to the subroutine. In absence of that argument, the routine may use any odd length.
I suggest that OP uses the ISO_C_BINDING feature to avoid this as well as the naming convention dependency - see the commented #define. Using that feature means that the interfacing between C and Fortran becomes platform-independent.
I puzzled over this in the previous posting location. OP tried to use the legacy appended string length argument, but there might be a data type mismatch between the std C strlen() function and the expected type for the Fortran implicit string length (would (int) cast paper over this?). As Arjen said, upgrading the code to Fortran 2003 might avoid some confusion and permit the compiler to do some checking (as would more correct use of includes on the C side).
I don't know how conio.h could be expected to be portable across the range of platforms quoted here.