Re: is it possible to pass C++ vectors to fortran subroutines

glen herrmannsfeldt wrote:

With C, and I believe also C++, many of the implementation details
are in the header files.

I'm not trying to turn this into a semantic argument, but I think that implementation may have two interpretations here.

One is that what's in the header files is sort of communication from programmer to compiler.

I think the second is more complicated and is what a particular compiler may do.

For example, I don't think that there's any limitation that says that arguments have to be passed in a particular order. I think an implementation can choose.

> A compatible Fortran implementation would
> then have the appropriate matching details in header or module files
> so that it would be hidden to the user, but match the C++
> implementation.

That sounds like a compatible implementation would either have to have hooks into, or implement, a c++ compiler. Don't forget the preprocessor and don't forget template meta-programming. And the new stuff coming down the pike for constants.

(For where I got the links below and links to stuff on constexpt and more see http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!291.entry)

So long as the fortran code is calling the code generated by the c++ compiler, because just reading the headers isn't enough to insure compatible functionality with a particular class.

I think the order of structure members has to be preserved, but alignment is another issue. Help for that may be coming: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf
and some limited help for C compatibility may be coming too: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm.

But I think there are still a few interesting issues, like how to deal with vtables.


That makes some assumptions on interoperability
between the C and C++ compilers, though.

A few. ;)

I'm not saying that it's impossible to do this. I'm not saying it's bad. I just think that it's likely to be difficult.

I think that what is required, or maybe that's too strong a word, so maybe, what would be very useful, to do this is probably some other, maybe not so readable by humans, language that can act as a universal go between for fortran, c and c++ (and maybe something else thrown into the mix). This language probably has to have the ability to allow someone to turn, eg, c++ brand hamburger into fortran brand cow, or at least fortran brand hamburger. Maybe not a perfect analogy.

In any case, I think this is what my professors used to call non-trivial.

LR
.

Relevant Pages

  • Re: changing module files
    ... my previous post (Will Fortran 2003 Solve This Problem). ... C++ header files avoid that problem, because header files only declare the ... INTERFACE to class member functions. ... > Just because the implemention of the compiler is not in a standard does ...
    (comp.lang.fortran)
  • Re: Beware of /Zp1 compiler option when compiling for X64
    ... This problems are not isolated to X64 compiles. ... Looking at the latest SDK header files and the Feb 2003 version that I had ... I am going to follow your advice about protecting the Windows SDK header ... Eventually I realised that the problem was caused by the compiler options ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Header Files and Interfaces Yet Again
    ... >> The point that I hope to get across is that header files need to provide ... a compiler has to know about them at compile time. ... But he actually uses what you call a fake header. ... differences between Java and C++: In Java all obects appear to be handles. ...
    (comp.lang.cpp)
  • Re: Way to autogenerate C/C++ Headers?
    ... able to supply the appropriate pointer type. ... translate Fortran module source files to C than to achieve the ... A completely automatic conversion from C interfaces to Fortran ... Trying to convert different C header files "found in the ...
    (comp.lang.fortran)
  • Re: Beware of /Zp1 compiler option when compiling for X64
    ... Stopping using Zp1 could potentially be a big deal for me. ... I make every effort to make sure that all my public header files work with ... whatever global packing option the user wants to use. ... Eventually I realised that the problem was caused by the compiler options ...
    (microsoft.public.win32.programmer.kernel)