Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Conversion of Fortran File unit to C File stream


Hello

I am using a data file which is opened in FORTRAN and the same file
goes inside the C code for  writing. I send the file unit in the
fortran part and the same needs to be mapped to the File stream on
entering in to C so that i can continue working with the same file. I
wonder if this conversion is possible.
My scenario looks like this....
void fprint_message(int fileUnit)
{
      /* conversion from fileUnit to File *f should happen here*/

      call cprint_message(File *f);

}

Here i call fprint_message from Fortran and before this the file is
opened. Kindly help me out if any of you have ideas on this.

Arun

<abaru@gmail.com> wrote:
> I am using a data file which is opened in FORTRAN and the same file
> goes inside the C code for  writing. I send the file unit in the
> fortran part and the same needs to be mapped to the File stream on
> entering in to C so that i can continue working with the same file. I
> wonder if this conversion is possible.

It is possible with some compilers, but it is *HIGHLY* system dependent.
This kind of capability is explicitly excluded from even the f2003 C
interop features.

While it can sometimes work, there are all kinds of subtleties that can
cause problems. One of the more "obvious" ones is that the Fortran
runtimes might buffer data in such a way that trying to intermix C and
Fortran I/O can cause data to get on the file in the "wrong" order.

I highly recommend that you do the I/O to each file with only one
language. You can use different languages for different files. Actually,
you can do it for the same file if you close the file on one language
before opening it in the other, which can be a major bother.

What I recommend is that, if the file is opened in Fortran, you can
provide a small Fortran wrapper procedure to write to the file and then
call this Fortran procedure from any C code that needs it. Or
conversely, if the file is opened in C, provide a small C wrapper
function to write to the file and call that from any Fortran code that
needs it. Choose one of those two options.

Although I repeat my recommendation against it, ff you feel that you
really need to intermix the I/O in a compiler-dependent way, then people
would need to know what compiler you were using. I've seen things for
that on some compilers, but it is compiler dependent. I'm afraid I don't
off-hand know the details for any particular compiler, as I follow my
own advice on this one. But others here might know. Be aware that it
might not be possible at all on some compilers.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

>Although I repeat my recommendation against it, ff you feel that you
>really need to intermix the I/O in a compiler-dependent way, then people
>would need to know what compiler you were using.

Strongly seconded.  Although I've made code with I/O to the same
file in both C and Fortran work, I do NOT recommend going this route.
It is WAY too system dependent and minor changes to build environment
can cause it to break.

Consider this to be a "waltzing bear" thing.  The wonder is not how
well the bear waltzes, the wonder is that the bear waltzes at all.

FInally, if you decide to go ahead with that foolishness anyway,
you will need to be very explicit about the compilers used, and
dev environment and target.

On May 12, 11:13 am, abaru@gmail.com wrote:

Yes, don't do it that way!

You can pass a "string" containing formatted text between languages
instead. In C you have sprintf. In Fortran you have internal write.
It's far easier to figure out how to pass a string between languages.
Even so, you need to provide details of compiler, operating system,
etc.

-- elliot

I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
compaq visual fortran for Win32. I too not in favor of mixingup
languages for I/O operation. Because of some project related
constraints i have to do like this.

On 14 mei, 11:56, abaru@gmail.com wrote:

Your best bet is still to delegate all I/O to a (small) set of
subroutines/functions
written in one language. Especially since you mention three completely
different compilers and platforms, it will be a gargantuan task to use
the
mixture you asked for. That way you can focus on the much simpler
task of creating a mixed-language program. There is more than enough
expertise in this newsgroup to help with that.

Regards,

Arjen

>I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
>compaq visual fortran for Win32. I too not in favor of mixingup
>languages for I/O operation. Because of some project related
>constraints i have to do like this.

I don't know much about Unix compilers, when I did this stuff
it was for 16 bit real mode DOS and Win32 console mode targets.
We used MS Fortran PDS 5.1 with MS VC 1.52c for the 16 bit
stuff and for the Win32 stuff we used both MS FPS4 with VC 4
and Watcom F77 & C/C++ both v10.6.

I can tell you that I am pretty sure it canNOT be done with
CVF and any C/C++ compilers for Win32.  When the FPS4/VC4
code was migrated to DVF5/VC5 the simultaneous dual-language
I/O to the same file broke badly.  It only worked on FPS4/VC4
because MS used the VC4 runtime as the basis for the FPS4 runtime.
When Digital introduced DVF5 as the FPS4 successor, we got a much
better compiler, but two distinct, separate runtimes.  The
MS PDS 5.1 w/ VC 1.52c and the Watcom F77 & C/C++ work for the
same reason -- for both the Fortran RTL is built on top of the
C RTL.

TO do this in Unix you would either need a Fortran built on C
and USING THE C RTL AS THE BASIS FOR THE FORTRAN RTL --or--
you will need to get into RTL implementation arcana.
That sounds like G77/GCC or G95/GCC or GFortran/GCC are probably
your best candidates.  F2C and any decent C compiler is another
possibility.

For Win32, OpenWatcom is one option, the GNUish toosets mentioned
are another and F2C is your fall-back.

Now, that I've outlined the steps needed, I ask you once again
to reconsider.  If you are still sure you wish to pass through
the portal under the "abandon all hope, ye who enter here" then
ask away.  I'll try to answer any questions you ask.

abaru@gmail.com wrote:
> I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> compaq visual fortran for Win32. I too not in favor of mixingup
> languages for I/O operation. Because of some project related
> constraints i have to do like this.

When I worked with the HP-UX compiler some years ago, maybe HP-UX
7.0 or so, it was easy to do.  The Fortran library used the C library
to do its I/O, and included functions that allowed one to mix them.
I believe one to find the C stream for an open Fortran unit, and
another to connect a Fortran unit to an open stream.

That would likely not be portable to Linux or Win32.

-- glen

In article <1179136560.520819.142@e65g2000hsc.googlegroups.com>,

 abaru@gmail.com wrote:
> I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> compaq visual fortran for Win32. I too not in favor of mixingup
> languages for I/O operation. Because of some project related
> constraints i have to do like this.

I think at least the HP compiler supports the POSIX interface
routines.  These allow fortran to do I/O through C file descriptors.  
If the other compilers also support POSIX, then that is probably the
easiest and most portable way to achieve what you want with a
minimum of wheel reinvention.

$.02 -Ron Shepard

On May 12, 8:13 am, abaru@gmail.com wrote:

Check if your Fortran implementation supports the function getfilep.

Bob Corbett

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc