- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi. I just sent this as an email to Compaq, but maybe someone here can tell me if I am making any sense or not, and perhaps help me out.
I am using CVF6.6B under Windows ME (Pentium III 1.0 GHz processor, 512MB Ram), with the /stand:f95 compiler option set. I often use PURE functions with dummy arguments that have the INTENT(INOUT) attribute, such as:
and the compiler doesn't complain, and the program that executes such functions compiles and runs (apparently) just fine. However, reading the PURE help page in the documentation, I notice that in fact, PURE functions are only allowed to have dummy arguments which are INTENT(IN) unless they are pointer or procedure arguments (which mine are not), so that actually my code isn't standard conforming. (Please correct me if I am wrong or have misunderstood.) The reason for using standards checking was that I wanted the code to be portable, and I only noticed the problem when starting to port it.
Is the fact that CVF accepts the functions with dummy arguments that have the INTENT(INOUT) attribute an extension to the f95 standard, and if so, shouldn't this be highlighted in the documentation? If I am correct that a f95 standards check has been missed, it's an important one, and I hope that it can be ammended quickly so that other people don't have the same problem as me.
I believe I will now have to alter the code that I thought I had written to take full advantage of PURE procedures, either so that those functions mentioned above and any that execute those functions aren't PURE anymore (which is annoying), or I will have to restructure those functions mentioned above somehow. Does anyone have any suggestions for the best way to do this?
Cheers,
Paul
I am using CVF6.6B under Windows ME (Pentium III 1.0 GHz processor, 512MB Ram), with the /stand:f95 compiler option set. I often use PURE functions with dummy arguments that have the INTENT(INOUT) attribute, such as:
PURE REAL FUNCTION demonstrate_it_fun(dummy) RESULT(ans) IMPLICIT NONE REAL, INTENT(INOUT), DIMENSION(:) :: dummy ... END FUNCTION demonstrate_it_fun
and the compiler doesn't complain, and the program that executes such functions compiles and runs (apparently) just fine. However, reading the PURE help page in the documentation, I notice that in fact, PURE functions are only allowed to have dummy arguments which are INTENT(IN) unless they are pointer or procedure arguments (which mine are not), so that actually my code isn't standard conforming. (Please correct me if I am wrong or have misunderstood.) The reason for using standards checking was that I wanted the code to be portable, and I only noticed the problem when starting to port it.
Is the fact that CVF accepts the functions with dummy arguments that have the INTENT(INOUT) attribute an extension to the f95 standard, and if so, shouldn't this be highlighted in the documentation? If I am correct that a f95 standards check has been missed, it's an important one, and I hope that it can be ammended quickly so that other people don't have the same problem as me.
I believe I will now have to alter the code that I thought I had written to take full advantage of PURE procedures, either so that those functions mentioned above and any that execute those functions aren't PURE anymore (which is annoying), or I will have to restructure those functions mentioned above somehow. Does anyone have any suggestions for the best way to do this?
Cheers,
Paul
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Paul,
You should have by now received my response that this is a bug that will be fixed. The compiler should not allow this combination.
I did also comment that the error and standards checking in the compiler is a useful diagnostic tool, but should not be considered a "validation" of your application.
Steve
You should have by now received my response that this is a bug that will be fixed. The compiler should not allow this combination.
I did also comment that the error and standards checking in the compiler is a useful diagnostic tool, but should not be considered a "validation" of your application.
Steve

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