- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I noticed that Visual Fortan has some sample code. I might be nice to have some samples for Linux Fortran.
In looking at the VS9 samples, I noticed quite a few non-standard feature. Using '.' instead of '%' for structure member selectors is nic; it would be nice if that were standard Fortran. However, I'm not sure the non-standard hex syntax is an improvement over the Z'...' syntax. I also think .AND. as a binary operator is a bit misleading. Why not have .IAND., etc. ?
But, overall, this:
FPCW = CTX.FloatSave.ControlWord .AND. 16#0000FFFF
Is much easier to read than this:
FPCW = IAND( CTX % FloatSave % ControlWord, Z'0000FFFF')
In looking at the VS9 samples, I noticed quite a few non-standard feature. Using '.' instead of '%' for structure member selectors is nic; it would be nice if that were standard Fortran. However, I'm not sure the non-standard hex syntax is an improvement over the Z'...' syntax. I also think .AND. as a binary operator is a bit misleading. Why not have .IAND., etc. ?
But, overall, this:
FPCW = CTX.FloatSave.ControlWord .AND. 16#0000FFFF
Is much easier to read than this:
FPCW = IAND( CTX % FloatSave % ControlWord, Z'0000FFFF')
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The dot separator is a DEC Fortran extension which pre-dates the F90 standard. You havea lot of company in finding it easy to read, and the argument about . vs. % raged on in comp.lang.fortran over the years.
The # syntax for hex constants is from Microsoft Fortran PowerStation. Please note that it is not the same as the standard Z syntax, in that the # syntax denotes an integer constant, whereas the Z syntax's type is context-dependent.
I can't agree regarding .AND. - don't confuse logical operators with the integer "bitwise" intrinsics such as IAND.
As for samples, nearly all of the Visual Fortran samples are illustrating use of Windows-specific features. I agree that it would be nice to have something comparable for Linux, but I don't see people coding Linux system calls in Fortran all that much. What did you have in mind?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> I can't agree regarding .AND. - don't confuse logical operators
> with the integer "bitwise" intrinsics such as IAND.
But the .AND. is, in fact, providing a bitwise AND in example above. I assume it becomes a bitwise AND because both args are integers. However, I just tested and found that it also accepts (integer .AND. logical) which returns the integer value or zero, meaning that the logical gets promoted to an integer.
I'll have to think about what examples would be good fo Linux. I think that signal handling amd mixed-language examples would be relevant. OpenGL would be nice, but requires the OpenGL interface. Maybe interfacing C-based libraries will become common with F2003.
> with the integer "bitwise" intrinsics such as IAND.
But the .AND. is, in fact, providing a bitwise AND in example above. I assume it becomes a bitwise AND because both args are integers. However, I just tested and found that it also accepts (integer .AND. logical) which returns the integer value or zero, meaning that the logical gets promoted to an integer.
I'll have to think about what examples would be good fo Linux. I think that signal handling amd mixed-language examples would be relevant. OpenGL would be nice, but requires the OpenGL interface. Maybe interfacing C-based libraries will become common with F2003.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah, you really need to read my Doctor Fortran article on the LOGICAL type.
I actually have a Linux OpenGL Fortran application, but it requires building three separate external libraries to make it work, so it doesn't make for a good sample. Mixed language is good and easy.
I actually have a Linux OpenGL Fortran application, but it requires building three separate external libraries to make it work, so it doesn't make for a good sample. Mixed language is good and easy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I learned FORTRAN on G77, which does not have bitwise '.AND.'.
I still think .IAND. would be a better bitwise operator extension, with .AND. always demoting values to logical, sort of like C's & and &&. Is there a switch in Intel Fortran to disable, or at least warn about, mixing logical operators with integer values? Using -nofpscomp does not disable it.
As for OpenGL Fortran examples, how many Windows Fortran programmers actually use advanced programming interfaces from Fortran? Would it be worthwhile to have IFOPNGL for Linux?
I still think .IAND. would be a better bitwise operator extension, with .AND. always demoting values to logical, sort of like C's & and &&. Is there a switch in Intel Fortran to disable, or at least warn about, mixing logical operators with integer values? Using -nofpscomp does not disable it.
As for OpenGL Fortran examples, how many Windows Fortran programmers actually use advanced programming interfaces from Fortran? Would it be worthwhile to have IFOPNGL for Linux?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is not a switch to disable integer-logical conversions, but if you ask for standards checking, the compiler will diagnose it.
For OpenGL, the preferable solution would be William Mitchell's f90GL, which I have built and used on Linux. It relies on GLUT and Mesa.
You'd be amazed at how many Windows Fortran programs use advanced Win32 API calls. Many of them are to provide a GUI for their application, but programmers are also using threading, file system, memory management calls and more. On Linux, Fortran programmers tend much more to strict computational applications.
For OpenGL, the preferable solution would be William Mitchell's f90GL, which I have built and used on Linux. It relies on GLUT and Mesa.
You'd be amazed at how many Windows Fortran programs use advanced Win32 API calls. Many of them are to provide a GUI for their application, but programmers are also using threading, file system, memory management calls and more. On Linux, Fortran programmers tend much more to strict computational applications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Linux users also can do better with plain Fortran because there are a lot of standard text manipulation tools, and the command shell is so much better.
As for OpenGL and F90GL: This looks like a fairly complex hand written OpenGL interface. I have been experimenting with automated interface generation with a Fortran module for SWIG. I was planning to wait for F2003 features, but I think this could be useful now using the !DEC$ features. Do MS-Windows users already have tools for this, or do people generally create these interfaces by hand? If not, how much interest is there for one?
Also, do you know if F2003 C-interop is designed well enough to be able to replace the !DEC$ methods?
As for OpenGL and F90GL: This looks like a fairly complex hand written OpenGL interface. I have been experimenting with automated interface generation with a Fortran module for SWIG. I was planning to wait for F2003 features, but I think this could be useful now using the !DEC$ features. Do MS-Windows users already have tools for this, or do people generally create these interfaces by hand? If not, how much interest is there for one?
Also, do you know if F2003 C-interop is designed well enough to be able to replace the !DEC$ methods?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know what others do - I've used some scripts for doing initial conversions of C interfaces. The idea of f90GL is that it is Fortran-friendly and portable.
The F2003 C interop features are helpful but don't do everything the extensions do.
The F2003 C interop features are helpful but don't do everything the extensions do.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page