intent(out) for pointer dummy argument
Damian
arguments. I've found this very useful in the intent(in) case and it
has some use for "intent(out)", but I have a hard time imagining the
utility of "intent(out)" for a pointer because presumably this leads
to an undefined state for the pointer, which would never seem to be a
good thing.
With one compiler, code analogous to the one below appears to leave
the pointer in some quantum superposition of associated and not
associated, wherein the conditional "if" succeeds, but the deallocate
fails (I get a run-time error saying I tried to deallocate an
undefined pointer):
subroutine f(x_pointer)
type(x) ,pointer ,intent(out) :: x_pointer
if (associated(x_pointer)) deallocate(x_pointer,stat=status)
I imagine this behavior conforms with standard (although I have not
checked the standard to be sure), so I'd like to suggest to the
standard committee that this be disallowed in the future. Can anyone
think of any good reason to allow "intent(out)" for a pointer
argument?
Damian
sturlamolden
> Fortran 2003 added the ability to specify intent for pointer dummy
> arguments. I've found this very useful in the intent(in) case and it
> has some use for "intent(out)", but I have a hard time imagining the
> utility of "intent(out)" for a pointer because presumably this leads
> to an undefined state for the pointer, which would never seem to be a
> good thing.
I don't use Fortran 2003, and I don't particularly like pointers, for
which this is an example. So please forgive my ignorance:
- Does the intent(out) refer to the pointer or its target?
Sturla
Richard Maine
> Fortran 2003 added the ability to specify intent for pointer dummy
> arguments. I've found this very useful in the intent(in) case and it
> has some use for "intent(out)", but I have a hard time imagining the
> utility of "intent(out)" for a pointer because presumably this leads
> to an undefined state for the pointer, which would never seem to be a
> good thing.
Well, yes, undefined states are problematic, for pointers or anything
else. There are also many ways to get them. Pointers have always had an
undefined state. They normally start life that way unless you you do
something special to make them otherwise. There are quite a lot of ways
that they can become undefined. Some of the ways can be tricky in that
they relate to things in parts of the code that migt be far away and
apparently unrelated. For example, the pointer's target can "go away"
for unobvious reasons, such as going out of scope of being deallocated
via some other poonter to the same target. Getting rid of intent(out)
would do little to prevent undefined pointer association status, as it
is not one of the more common causes.
Why would you think intent(out) for a pointer was inherently any
different from intent(out) for anything else in this regard? Intent(out)
for a non-pointer causes undefinition in much the same way. Is it just
that errors with pointers have a tendency to have more dramatic effects
(like invalid memory references) than errors with most non-pointers?
That's a general property of pointers. There are questions about whether
the intent best applies to the pointer or its target, but that seems an
unrelated matter.
The notion of intent(out) for a pointer is just like that of intent(out)
for a non-pointer. It has the same reasons and uses. (Again, I'm not
talking about the distinction between the pointer and its target, which
I regard as completely unrelated). Much of the reason for adding intent
(of all kinds) for pointers in f2003 was regularization. To my
knowledge, the only reason pointers didn't have intent in f90 was
because of the debate about what the intent should apply to. I don't
know that there was any suggestion that intent for pointers was not a
useful concept. I suppose I could be wrong about that, as I was not
there during the development of f90, but I don't recall ever hearing any
other objection to intent for pointers.
In particular, its main use is to help diagnose bugs. The compiler can
sometimes tell at compile time that you have tried to reference an
intent(out) argument before it could possibly be defined. Some compilers
can also manage run-time checks for some cases. There are several
occurances of "some" in the above two sentences. All cases won't be
caught, but some will.
A secondary use is in optimization; copy-in can sometimes be skipped.
> With one compiler, code analogous to the one below appears to leave
> the pointer in some quantum superposition of associated and not
> associated, wherein the conditional "if" succeeds, but the deallocate
> fails (I get a run-time error saying I tried to deallocate an
> undefined pointer):
>
> subroutine f(x_pointer)
> type(x) ,pointer ,intent(out) :: x_pointer
> if (associated(x_pointer)) deallocate(x_pointer,stat=status)
>
> I imagine this behavior conforms with standard (although I have not
> checked the standard to be sure), so I'd like to suggest to the
> standard committee that this be disallowed in the future. Can anyone
> think of any good reason to allow "intent(out)" for a pointer
> argument?
Yes, see above. Code like that is almost always a bad idea for pointers,
completely independent of intent for dummy arguments. That's because
there are *MANY* ways for pointer association status to become
undefined. Getting rid of intent(out) would not fix the problem. Even
without the intent(out), the above code could stil fail; it would do so
if the actual argument had undefined association status.
Pointers are error prone. There are many reasons. That's largely a fact
of life. Simple changes like this aren't going to fix that. That's why
it is often recommended to avoid pointers and use other facilities (such
as allocatable) when the other facilities can apply.
Undefined pointer association status is one of the reasons pointers are
error prone. You have to be quite meticulous to avoid problems with it.
If you think the above problem is caused largely by the intent(out) of
the dummy, then I'm guessing you have largely missed the whole issue of
undefined association status, but just happened to run into it first
here.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Richard Maine
> I don't use Fortran 2003, and I don't particularly like pointers, for
> which this is an example. So please forgive my ignorance:
>
> - Does the intent(out) refer to the pointer or its target?
The pointer. For a few reasons. I'll probably miss some, as I don't want
to spend more than a minute or two on this right now. Off the top of my
head.
1. It is (ahem) pointless to have it apply to the target because that
would have little effect due to the possibility of multiple pointers
having that same target. That possibility is inherent to pointers and
permeates throughout the standard, specifically including several things
relating to dummy arguments. For example, pointer targets are an
exception to the general prohibition against changing the value of a
dummy argument other than through the dummy; it is assumed that it is
"normal" for pointer targets to change other than through the pointer.
So if you have, for example, intent(in) to keep the value from changing,
the value coiuld change anyway via some other pointer; disallowing that
would be contrary to the whole way pointers work.
2. It is, however, a useful facility to have an intent for the pointer
and there is no other option to achieve that.
That being said, people did debate the issue and some probably still
disagree with the decision that came about. I don't think I'll debate it
beyond having advanced the above points. Been there before.
Regardless of whether one agrees with the reasons or not, the answer in
the standard is that it applies to the pointer (or to speak more
strictly - to the association status of the pointer).
sturlamolden
> Regardless of whether one agrees with the reasons or not, the answer in
> the standard is that it applies to the pointer (or to speak more
> strictly - to the association status of the pointer).
Thanks :-)
Sturla
Ron Shepard
<23917930-2743-422e...@r4g2000prm.googlegroups.com>,
Damian <dam...@rouson.net> wrote:
> subroutine f(x_pointer)
> type(x) ,pointer ,intent(out) :: x_pointer
> if (associated(x_pointer)) deallocate(x_pointer,stat=status)
>
> I imagine this behavior conforms with standard (although I have not
> checked the standard to be sure), so I'd like to suggest to the
> standard committee that this be disallowed in the future. Can anyone
> think of any good reason to allow "intent(out)" for a pointer
> argument?
If I understand your question correctly (I think there was a typo
between "out" and "inout" in your original post), this is the same
situation as any other intent(out) dummy argument. For example
subroutine f(k)
integer, intent(out) :: k
if ( k < 0 ) k=...something...
The argument has undefined status until it has been defined
(assigned a value), so it is not allowed to reference it in an
expression (in this case, the k<0 expression). The standards
committee does not need to do anything new, this situation is
already disallowed. Variables can become undefined for all kinds of
reasons, some like the above are obvious, others are not as easy for
the programmer or for the compiler to see. A compiler might well
recognize the above situations, both of them, and print an error
message, but there are many situations involving undefined status
that cannot be detected at compile time, so it is not possible to
require all situations to be detected.
In the above, the integer k is represented by some string of bits.
That string of bits is undefined for a variable in an undefined
state. So if you test it, you might well have a negative value, in
which case the conditional expression would be executed. That code
is still disallowed by the compiler, even though it might appear to
work the way you expected. For some reason, this is easier for me
to understand than the pointer case, but it is the same situation
nonetheless. In the pointer case, there is some string of bits
somewhere that the associated() intrinsic uses to determine its
result. If that string of bits happens to have some set of values
then it returns .true., and if it has some other set of values it
returns .false. But just as in the integer case, it is disallowed
to test those bits when they are undefined.
If the dummy argument intent were changed from out to inout (or to
in or unspecified), then the above examples, both of them, would
still be disallowed if the actual arguments were undefined. It is
still disallowed to test those bits, regardless of how or why they
are undefined. In these cases, it is even less likely for the
compiler to ever be able to recognize that it is disallowed. But as
far as the standards committee goes, I think they have already
covered this situation.
$.02 -Ron Shepard
glen herrmannsfeldt
(snip)
> The argument has undefined status until it has been defined
> (assigned a value), so it is not allowed to reference it in an
> expression (in this case, the k<0 expression). The standards
> committee does not need to do anything new, this situation is
> already disallowed. Variables can become undefined for all kinds of
> reasons, some like the above are obvious, others are not as easy for
> the programmer or for the compiler to see. A compiler might well
> recognize the above situations, both of them, and print an error
> message, but there are many situations involving undefined status
> that cannot be detected at compile time, so it is not possible to
> require all situations to be detected.
Yes, the results are often "segmentation fault" or something
similar for pointers, but just large or small numbers for
non-pointers. (A common cause for floating point overflow and
underflow is floating point values that are undefined.)
Sometimes a pointer will accidentally have a valid pointer, that
may not point to where you expect. One that I had to debug,
written by someone else in C++, would run out of memory, but
not a segmentation fault. It turned out to be a routine that
was deallocating a linked list (or maybe tree) recursively.
The undefined pointer did point to another pointer, which did
point to another pointer, thousands of pointers down before
one finally pointed to a previous pointer for a loop.
It isn't hard to imagine a small pointer loop accidentally
forming, but this one was thousands of pointers around.
(As part of debugging it, I put in code to check for the
size of the loop, otherwise I would never have known.)
-- glen
Damian
wrote:
> In article
> <23917930-2743-422e-b8ee-9eb31c0e1...@r4g2000prm.googlegroups.com>,
Yes, there was a typo. I meant to write that while I see some use for
"intent(inout)" with pointers, I see no use for "intent(out)".
I think I was misunderstanding the philosophy of writing a standard.
Prohibiting access to a pointer in an undefined state is useful only
so long as programmers obey that prohibition. In situations where a
compiler can enforce the prohibition, that would seem to be a good
thing. The point I was probably not understanding is that it's not the
role of the standard to dictate that a compiler police the programmer
in such cases.
Putting the standard aside, I think in the specific case I'm citing
(and hopefully we can focus on that and not all the other problems
that crop up with pointers), it would be very easy for a compiler to
reject such code. While there are many of the problems pointers might
be difficult or impossible for a compiler diagnose, this one seems
clear to me. I haven't heard any good reasons why "intent(out)" would
ever serve a useful purpose for a dummy argument with the pointer
attribute.
As an aside, I'm no fan of pointers. I strongly advocate against
using them whenever there are better alternatives. However, there are
situations in which their use is more natural and flexible than the
alternatives (e.g., with linked lists) and there are cases when they
are pretty much unavoidable (e.g., in wrapping C/C++ code).
Damian
Wolfgang Kilian
> Fortran 2003 added the ability to specify intent for pointer dummy
> arguments. I've found this very useful in the intent(in) case and it
> has some use for "intent(out)", but I have a hard time imagining the
> utility of "intent(out)" for a pointer because presumably this leads
> to an undefined state for the pointer, which would never seem to be a
> good thing.
> Can anyone
> think of any good reason to allow "intent(out)" for a pointer
> argument?
As others have said, the possibility of undefined state is not an issue
that applies specifically to intent(out).
To answer the question, yes, of course:
A simple pointer assignment
integer, pointer :: a, b
b = 0
a => b
can be transferred to a subroutine:
call assign_ptr1 (a, b)
[...]
subroutine assign_ptr1 (x, y)
integer, pointer, intent(out) :: x
integer, pointer, intent(in) :: y
x => y
end subroutine assign_ptr1
which makes sense if the subroutine does more useful things apart from
the assignment. intent(out) is appropriate since the previous value of
x is irrelevant. This is not a rare situation.
Actually, I often write instead
call assign_ptr2 (a, b)
[...]
subroutine assign_ptr2 (x, y)
integer, pointer, intent(out) :: x
integer, target, intent(in) :: y
x => y
end subroutine assign_ptr2
which has the same effect if b is associated. Furthermore, it can be
(re)used if b is _not_ a pointer. If b is disassociated, assign_ptr1
doesn't care, while assign_ptr2 crashes at runtime, which yields a
useful traceback, when appropriate compiler options are set. Hence,
assign_ptr2 is preferable if disassociated is not an allowed state for
the application, otherwise use assign_ptr1.
In summary, for me it looks like intent(out) might be the most common
use of Fortran pointer dummy arguments. intent(in), pointer can often
be replaced by intent(in), target, and intent(inout) is less common.
Maybe this is just personal style.
BTW, some compilers are reliable in detecting undefined (pointer) state
and pointing at the source of the trouble, so debugging is not THAT
difficult ...
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
Wolfgang Kilian
> integer, pointer :: a, b
allocate (b) ! ;)
> b = 0
> a => b
Richard Maine
> Putting the standard aside, I think in the specific case I'm citing
> (and hopefully we can focus on that and not all the other problems
> that crop up with pointers), it would be very easy for a compiler to
> reject such code. While there are many of the problems pointers might
> be difficult or impossible for a compiler diagnose, this one seems
> clear to me. I haven't heard any good reasons why "intent(out)" would
> ever serve a useful purpose for a dummy argument with the pointer
> attribute.
Well now you really puzzle me because you seem to contradict yourself.
First you say that you think a compiler ought to be able to reject this
code. Then you say that you don't see any use for intent(out) for
pointers.
But intent(out) for pointers is the only thing that allows a compiler to
be able to reject this code.
That doesn't mean all compilers will do so, but with intent(out), at
least there is the possibility. That sounds like a useful purpose to me.
I thought you were also saying that would be useful, but then you say
you don't see a use? Something seems missing here.
The only thing I can think is that you don't realize that it is only the
intent(out) that makes it possible for a compiler to detect this, at
least at compile time. Without the intent(out), it is perfectly valid
code - at least in isolation - and there is just no way a compiler is
going to reject it at compile time. Odds are high that it is used
incorrectly, because that's the case for most associated tests like
that. But the compiler can't plausibly criticise like that. So the
intent(out) took code that was probably wrong, but could not be
diagnosed, into code that could be diagnosed as wrong.
If you think that a compiler could reasonably detect the problem without
the intent(out), then you do not understand the other problems that crop
up with pointers, and no, you can't just ignore them as unrelated. They
are intimately related.
I think I'll maintain that as long as you don't see a use for
intent(out), that probably means you don't yet understand it. I assure
you it is *NOT* going to go away. After all, it was quite deliberately
added in f2003. It isn't as though it was some case that slipped in
without anyone noticing it.
If it doesn't do what you want in some particular case, then don't use
it there. Though in the case you showed, I'd lay odds that your code
would still be wrong - just in ways that are harder to check.
Ian Harvey
> I haven't heard any good reasons why "intent(out)" would
> ever serve a useful purpose for a dummy argument with the pointer
> attribute.
You have a procedure. You want that procedure to pass back a pointer to
the calling context.
You want to make it clear to all and sundry that the association status
and possible target of the actual argument pointer prior to the call to
the procedure is irrelevant. Similarly, you want to make it clear that
irrelevance also applies to the dummy argument pointer inside the
procedure, until you get around to defining the dummy argument pointer
in some way.
I use INTENT(OUT), POINTER on dummies where it suits, so it seems pretty
useful to me.
Are you actually advocating for INTENT(OUT) pointers to have their
association status automatically set to "not associated" on procedure
entry? I think the arguments for that, given the behaviour of the rest
of the language, are a bit weak.
Damian
To add a bit more context, I was trying to debug code not written by
me, so possibly my frustration is misplaced and should be directed at
the developer, but I think in this case, the compiler should be able
to help.
You certainly make a good point that it is only the "intent(out)" that
would allow the compiler to reject the code, but that's a catch 22 in
this case because the pointer came into the procedure defined, so the
code would have been valid without the "intent(out)". It's a bit like
saying it's good to add a flaw so the compiler can detect the flaw
(which in fact the compiler did not, so the point is moot). In
addition to making the access via the "associated()" intrinsic
invalid, the "intent(out)" also caused a memory leak so it was doubly
egregious code.
Damian
Damian
Rather than using "intent(out)" for that purpose, I think it would be
better style to associate the pointer with "=>NULL()" right away.
That way it's association status is never undefined. So maybe here's
another way to phrase what I'm saying: I don't see any value in having
a feature that is guaranteed to leave the pointer status undefined.
Of course, there are many other ways a pointer can become undefined,
so I hope we won't go down the path of enumerating all the other
ways. I just don't see any advantage this particular way has over the
alternative of associating the pointer with NULL() in the context you
describe.
Of course, my writing "right away" in the above paragraph opens
another can of worms. I think the best approach would be to associate
the pointer with NULL() in the declaration of the dummy argument, but
possibly that would imply the save attribute (I'd have to check the
standard on that), which could have unintended consequences. So I
guess by "right away" I simply mean immediately after the
declaration. Then, for all intents and purposes, the pointer never
exists in an undefined state.
What is the value in having a feature that is absolutely guaranteed to
render the pointer undefined rather than unassociated?
Damian
glen herrmannsfeldt
(snip)
> Yes, there was a typo. I meant to write that while I see some use for
> "intent(inout)" with pointers, I see no use for "intent(out)".
If the subroutine allocates it, or otherwise returns a pointer,
then it should be fine.
> I think I was misunderstanding the philosophy of writing a standard.
> Prohibiting access to a pointer in an undefined state is useful only
> so long as programmers obey that prohibition. In situations where a
> compiler can enforce the prohibition, that would seem to be a good
> thing. The point I was probably not understanding is that it's not the
> role of the standard to dictate that a compiler police the programmer
> in such cases.
Most of the time it isn't so much of a problem.
-- glen
glen herrmannsfeldt
> On Feb 19, 2:30 pm, Ian Harvey <ian_har...@bigpond.com> wrote:
>> On 20/02/2011 8:06 AM, Damian wrote:
>> > I haven't heard any good reasons why "intent(out)" would
>> > ever serve a useful purpose for a dummy argument with the pointer
>> > attribute.
>> You have a procedure. You want that procedure to pass back a
>> pointer to the calling context.
(snip)
>> Are you actually advocating for INTENT(OUT) pointers to have their
>> association status automatically set to "not associated" on procedure
>> entry? I think the arguments for that, given the behaviour of the rest
>> of the language, are a bit weak.
> Rather than using "intent(out)" for that purpose, I think it would be
> better style to associate the pointer with "=>NULL()" right away.
Or just ALLOCATE it right away. Then there is also no question
about its status.
> That way it's association status is never undefined. So maybe here's
> another way to phrase what I'm saying: I don't see any value in having
> a feature that is guaranteed to leave the pointer status undefined.
If a routine is going to allocate something and return a
pointer (often not a good idea), or otherwise return a pointer
(maybe related to its argument) then there is no need to assume
any specific status coming in for that argument.
> Of course, there are many other ways a pointer can become undefined,
> so I hope we won't go down the path of enumerating all the other
> ways. I just don't see any advantage this particular way has over the
> alternative of associating the pointer with NULL() in the context you
> describe.
(snip)
> What is the value in having a feature that is absolutely guaranteed to
> render the pointer undefined rather than unassociated?
Well, since they are undefined when the program starts, that
would also apply to all pointer variables.
-- glen
glen herrmannsfeldt
> Fortran 2003 added the ability to specify intent for pointer dummy
> arguments. I've found this very useful in the intent(in) case and it
> has some use for "intent(out)", but I have a hard time imagining the
> utility of "intent(out)" for a pointer because presumably this leads
> to an undefined state for the pointer, which would never seem to be a
> good thing.
> subroutine f(x_pointer)
> type(x) ,pointer ,intent(out) :: x_pointer
> if (associated(x_pointer)) deallocate(x_pointer,stat=status)
It is normally not necessary to do an if(associated(x)) before
every use of a pointer. There are cases where that is the best
way to keep track of the status of a pointer. Though for many of
those, you could keep a separate LOGICAL variable with the
allocation status. Note that the LOGICAL variable is also undefined
before you give it a value.
It is common, for example in binary trees, to use the associated
status to keep track of which branches have a node attached and
which don't. In that case, assign NULL when creating a new node.
If there is the possibility of the dummy argument pointing to
something that needs to be deallocated, then it needs to be
intent(inout).
-- glen
Richard Maine
> To add a bit more context, I was trying to debug code not written by
> me, so possibly my frustration is misplaced and should be directed at
> the developer, but I think in this case, the compiler should be able
> to help.
As I mentioned, some compilers can - or at least should be able to.
Apparently you were using one that didn't. I'd say thet, yes, your bitch
is first with the developer for writing the buggy code, and second with
the compiler for not providing a diagnosis for this case. Maybe you
should submit an enhancement request to the compiler vendor.
> You certainly make a good point that it is only the "intent(out)" that
> would allow the compiler to reject the code, but that's a catch 22 in
> this case because the pointer came into the procedure defined, so the
> code would have been valid without the "intent(out)".
You say so in this case. I'd bet good money that if it is a code of any
substantial size, that it isn't so in all cases in the code. I'll claim
that a developer that would write code like the sample shown has
negligable probability of getting them all right in a code of any size,
because the sample illustrates a fundamental misunderstanding of an
issue that needs meticulous attention.
And I am not talking about the intent(out). I'm talking about the
if (associated(pointer)) deallocate(pointer)
regardless of intent. There might be cases where a line of code like
that is justified, but they are in a small minority compared to the
many, many cases where that line illustrates a bug in the code. Having
it in a subroutine lowers the already negligable odds that the developer
understood the issue because it adds a subtle requirement to the
subroutine interface - again, I'm talking about the case without intent.
Does the developer document that this subroutien should never be called
with a pointer that has undefined association status? That would be
absolutely critical documentation for such a subroutine. Just relying on
the (assumed) fact that it happens to be so for the calls currently
codes is nowhere near adequate.
In any case, bitch if you like. It is *NOT* going to change. The odds of
that are about as low as the odds that a developer who would write code
like that understood the implications.
I'm not going to reply to this thread any more. If you don't agree with
my arguments, so be it. I have no more of them, and I don't see this
going anywhere constructive.
Richard Maine
> On Feb 19, 2:30 pm, Ian Harvey <ian_har...@bigpond.com> wrote:
> > Are you actually advocating for INTENT(OUT) pointers to have their
> > association status automatically set to "not associated" on procedure
> > entry? I think the arguments for that, given the behaviour of the rest
> > of the language, are a bit weak.
>
> Rather than using "intent(out)" for that purpose, I think it would be
> better style to associate the pointer with "=>NULL()" right away.
which is exactly what Ian was referring to when he said "the arguments
for that, given the behavior of the rest of the language, are a bit
weak." That's not how pointers act anwhere else in the language.
Damian
The best thing about knowing you won't reply to this thread any more
is that it's the only way to guarantee you won't insult or condescend
to anyone anymore. Despite the presumptuous and condescending
statements you've made about the level of knowledge of the developer
of that code, at least one of the co-authors of the overall module
knows Fortran 2003 better than you and, yes, I say that knowing that
you wrote a book on the language and that you used to be member of the
standards committee.
It's possible to be right without being rude. And it would be
especially valuable to those who read this newsgroup if one of the
most knowledgable people on the newsgroup would stick to the sharing
his knowledge without ad hominem editorializing.
Damian
Steven Correll
> I haven't heard any good reasons why "intent(out)" would
> ever serve a useful purpose for a dummy argument with the pointer
> attribute.
Ok, here is an example in which "intent(out)" keeps us from
erroneously defining an actual argument:
$ cat foo.f90
module mymodule
implicit none
integer, pointer, protected :: myprotected
contains
subroutine mysub(arg1, arg2, arg3)
integer, pointer, intent(out) :: arg1
integer, pointer, intent(in) :: arg2
logical :: arg3
if (arg3) then
! arg1 => arg1 ! This is a typo
arg1 => arg2
else
arg1 => null()
end if
end subroutine mysub
end module mymodule
use mymodule
implicit none
call mysub(null())
call mysub(myprotected)
end
steven-corrells-macbook-pro:foo sjc$ gfortran foo.f90 -c
foo.f90:20.13:
call mysub(null())
1
Error: Actual argument at (1) must be definable as the dummy argument
'arg1' is INTENT = OUT/INOUT
foo.f90:21.13:
call mysub(myprotected)
1
Error: Actual argument at (1) is use-associated with PROTECTED
attribute and dummy argument 'arg1' is INTENT = OUT/INOUT
And in theory "intent(out)" would enable a compiler to save us from
the hypothetical typo in the comment since static analysis shows that
arg1 is referenced before it is defined, although the two compilers I
have access to right now are not able to do so (anybody want to try
NAG?)
I like your proposal that the dummy pointer be implicitly initialized
to the "not associated" state, assuming you would propose likewise for
non-dummy pointer declarations, for the sake of consistency. But we'd
both be unpopular with people who don't want to pay the performance
penalty. In some compiler implementations I expect that would be
pretty cheap because it would be sufficient to store a single zero
word; but I am familiar with at least one implementation where that
wouldn't be sufficient. Reasonable minds can differ on the tradeoff
between performance and safety, but when it comes to implicit
initialization, Fortran long ago decided in favor of performance.
Damian
Thanks for an insightful and thoughtful response. I hadn't thought of
the performance implications. My understanding is that deciding in
favor of performance has long been a strong point of Fortran, so it
makes sense that the committee would play to language's strength when
deciding language features.
Damian
Richard Maine
> The best thing about knowing you won't reply to this thread any more
> is that it's the only way to guarantee you won't insult or condescend
> to anyone anymore. Despite the presumptuous and condescending
> statements you've made about the level of knowledge of the developer
> of that code, at least one of the co-authors of the overall module
> knows Fortran 2003 better than you and, yes, I say that knowing that
> you wrote a book on the language and that you used to be member of the
> standards committee.
>
> It's possible to be right without being rude. And it would be
> especially valuable to those who read this newsgroup if one of the
> most knowledgable people on the newsgroup would stick to the sharing
> his knowledge without ad hominem editorializing.
My patience for this kind of thing must be lower than it used to be.
Killfile addition made.
glen herrmannsfeldt
(snip)
> contains
> subroutine mysub(arg1, arg2, arg3)
> integer, pointer, intent(out) :: arg1
> integer, pointer, intent(in) :: arg2
> logical :: arg3
(snip)
> call mysub(null())
> call mysub(myprotected)
(snip)
> call mysub(null())
> 1
> Error: Actual argument at (1) must be definable as the dummy argument
> 'arg1' is INTENT = OUT/INOUT
> foo.f90:21.13:
And no diagnostics at all about the wrong number of arguments?
(snip)
-- glen
Steven Correll
wrote:
> Steven Correll <steven.corr...@gmail.com> wrote:
> > call mysub(null())
> > 1
> > Error: Actual argument at (1) must be definable as the dummy argument
> > 'arg1' is INTENT = OUT/INOUT
> > foo.f90:21.13:
>
> And no diagnostics at all about the wrong number of arguments?
Sorry, I did confuse the matter unnecesarily with that additional
error. With gfortran 4.6.0, you don't get a message about missing
arguments until the "intent(out)" problem is fixed.
Ron Shepard
<5fe6f628-5777-437c...@d23g2000prj.googlegroups.com>,
Damian <dam...@rouson.net> wrote:
> I haven't heard any good reasons why "intent(out)" would
> ever serve a useful purpose for a dummy argument with the pointer
> attribute.
I think it is the same as for any other intent(out) argument, the
compiler knows that the variable is in an undefined state on entry
to the subroutine, and the compiler knows in the calling program
that the variable is (or at least may be) changed when the
subroutine is called. All those things have implications w.r.t.
optimizations that are allowed, whether large arrays need to be
copied upon subroutine entry, and other similar things. It also
allows the compiler to match actual and dummy argument
characteristics and to issue warnings at compile time when things
don't match.
$.02 -Ron Shepard