Integration with .NET and its CLR

Integration with .NET and its CLR

I happened to see an ad for Salford FTN95 for Microsoft .NET and Win32. It claims that it will integrate with Visual Studio .NET and make calls to languages like C# easy to do.

Previous posts in this forum seem to indicate that the completely merged Intel/VF compiler due out in the second half of next year won't have this capability, or at least that's what I think they've said. Have I misunderstood something?

I don't need to use .NET and its CLR yet, but I might if .NET spreads everywhere like Microsoft claims (or hopes) it will.


14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

We have no current plans to have our Fortran compiler generate MSIL (.NET interpreted code), which is another way of describing the "CLR". We do plan to extend our COM compatibility features to facilitate mixing Fortran compiled code with .NET managed (interpreted) code, including automatic generation of interfaces to .NET modules.

This is not to say that we have no interest in generating MSIL, but our focus is elsewhere at present.


Retired 12/31/2016

One of the great things about Fortran is that it produces executables that run very fast. Surely MSIL will slow things down considerably.

More importantly (for me) - will the 'new' Fortran from Intel integrate with C++ and Visual Studio 7?

I don't necessarily care that much if the Fortran compiler generates MSIL, but I am interested in being able to mixed compiled Fortran with .NET managed code. It sounds like that's the plan. I agree with the comment that Fortran generates fast executables, and I don't want to see that screwed up.

Like Eddie, I also want to know if Intel Fortran will integrate with Visual Studio 7 (the same thing as Visual Studio .NET?) in the same way that CVF integrates with VS 6 today.

I remember a previous discussion thread in which Steve explained that creating a mixed language application to run in a .NET environment won't be as simple as creating such an application today. I guess that's the price we'll have to pay to play in Microsoft's new world.


Your questions don't have simple answers...

You can, even with CVF 6.6, mix Fortran code with .NET managed code. You can do this with a COM server, or a DLL. But Fortran can't "see" the .NET resources - we're working on an extension of the Module Wizard to provide enumeration of and generated interfaces for .NET modules - that won't arrive until the merged product.

Intel Fortran 7 uses the VS.NET IDE as its IDE. This means a common editing and debugging environment, and familiar (to VS.NET users) ways of specifying compiler options. So this much is like CVF...

But MS has changed the rules for mixed-language projects in VS.NET, which is going to make a lot of people unhappy. With the previous version (VS6 and CVF 6), a single project could have a mixture of Fortran and C/C++ files, and Developer Studio would sort it out, compile the sources and link them all together. No more...

In VS.NET, every language is in its own little room - you put the C++ code in a C++ project, and the Fortran code in a Fortran project. Each project, as before, has to build something, such as an EXE or LIB. So to create a mixed-language executable, you have one executable project, the other one is a library linked in by the first. Multiple projects are in a "solution", and you can build the solution, which is like a 6.0 project with subprojects.


Retired 12/31/2016

Hi Steve,
Is it still the case that you must have two separate projects in order to use two different languages? I'm not sure if anything has changed since this post was last updated (2002). The reason I'm asking is because I am trying to create a COM wrapper in C++ that wraps around a fortran DLL. It would be great if I could just add the fortran to the C++ project, but this may not be possible...?
Jason C.

It is still the case that you need to separate languages by project. However, have you looked at the COM Server feature in 10.0?

Retired 12/31/2016

I have read about it quite a bit, including thread #300150 specifically. I have zero experience with COM so far, and only a grad student's knowledge of Fortran; so, combining those two things seems a little daunting. I will try to follow that post I mentioned above, but does anyone have any posts/links that that are a little more....detailed?
Thanks, Steve.
Jason C.

If you're comfortable with the C++ wrapper, then that's fine, but I would not think that using the COM Server feature requires much more COM knowledge than writing a C++ wrapper would.

Retired 12/31/2016

I'm sure that's true. Here's a question about the same subject, different concept: how do I handle external subroutines when I place my fortran code into the com server? Specifically, I have the current (simplified) code:

subroutine reactor(temperature)
real*8 temperature
external TemFunc
!where TemFunc is a subroutine with its own arguments, outside the reactor subroutine
call Solver(TemFunc,temperature)
end subroutine reactor

What kinds of gyrations are needed in the COM server to allow this type of thing to happen? Is it even possible?

Thank you,
Jason C.

Perhaps I don't understand the question, but nothing special is needed. When you implement the COM server, there is Fortran code you fill in to do whatever is needed. If that means calling other routines in the project, that's fine.

Here's an excerpt of code you get when you walk through the COM server example in the documentation:

! IAdd_Add
function IAdd_Add( ObjectData ,&
Operand) result (hresult)
use AddingMachine_Types
implicit none
type(Adder_InstanceData) ObjectData
!dec$ attributes reference :: ObjectData
REAL(4) :: Operand
integer(long) hresult
ObjectData%CurrentValue = ObjectData%CurrentValue + Operand
hresult = S_OK
end function

The wizard generates template code and you fill in the "to do" parts, which is between the DO NOT REMOVE comments. This is ordinary code that can call anything you like.

Retired 12/31/2016

So I can just copy and paste the program body as it is right now into the To Do sections? I suppose every subroutine (at least those not currently contained in a "CONTAINS" block within another subroutine) will need to be placed in their own method? Is this correct?
Jason C.

I don't know what your code does. Since you say you are creating a C++ wrapper so that you can call the Fortran code from .NET, I suggested you could skip the C++ part. Your C++ code would define various methods with arguments that I assume you pass on to the Fortran code. Now you'd put the Fortran code in the "to do" sections, with modifications for how the arguments are accessed.

Any code that isn't directly called as a method can be put in a module and USEd or whatever structure you want.

Please understand that this is not a simple copy and paste exercise. First make sure you understand what your proposed wrapper looks like and decide what the corresponding Fortran should be. Read the chapter of the Fortran documentation on the COM server feature for more information. Start with the example it describes.

Retired 12/31/2016

I appreciate your help on this. I will repost with any other issues, but I think your suggestions will get me where I want to be.
Thanks again,
Jason C.

Leave a Comment

Please sign in to add a comment. Not a member? Join today