Peter Shenkin <[log in to unmask]>:
> Hi,
> I'm not sure I really see the problem. INTENT is always relative to
> the procedure within which it is specified. If, before the current
> procedure returns, the variable gets altered, then the INTENT cannot be
> IN. All your examples are consistent with this, and I don't see why
> PUBLIC or PRIVATE has anything to do with it.
I am afraid my explanations in my previous email were not very clear.
In my effort to keep the (already long) mail as short as possible, I
refrained from expressing the issues in detail. I am giving this
another shot.
I'd like to mention that I am not confused about the definition of the
INTENT attribute. The definition is precise, clear and unambiguous.
I, however, question the functionality of it.
I perceived (may be incorrectly), from explanations in different F90
books, three purposes for the INTENT attribute. They are
1) Help compiler to perform certain optimizations.
2) Provide guidelines to function/subroutine INTERFACE's as to define
the purpose of the argument variables. This can be done either
through .mod or .M files or through a module with INTERFACE
statements. For example, a fortran 77 library documentation will
specify whether an argument is INPUT, OUTPUT or WORK. I understood
that one of the purposes of INTENT is provide a similar facility within the
F90 language.
3) Catch misuses such as
a) changing INTENT(IN) variable, and
b) refering to an INTENT(OUT) before it is defined.
Using CODE1 and CODE2 in my previous posting, I have tried to show
that purposes (2) and (3) are not completely valid under some
conditions.
CODE1 demonstrates a library INTERFACE with a variable having
INTENT(INOUT) while as far as the user of the library is concerned, it
should be only INTENT(IN). One may avoid this problem by specifying
INTENT(IN) in an INTERFACE module. However, the problem will be
present if we are distributing .mod files.
I suggested a READONLY attribute for variable declarations in a
MODULE, since I believe that it would be, in general, useful. Whether
it is needed or useful in this situation is questionable and better
left for the experts to decide.
CODE2 shows the lack of sophistication in compilers with regard to
INTENT in catching potential misuses (Related to purpose 3).
> If you don't like the fact that printing a name from t_person prevents
> it from having INTENT(IN), then you should take the num_access variable
> that gets incremented and store it outside the structure, perhaps in some
> other structure private to the MODULE.
This is definitely a solution to the problem which conforms to F90
standard and satisfies my needs. However, the effort to manage the two
types and the information on which num_access corresponds to which
person will be enormous and makes the code cumbersome to
maintain. Moreover, "num_access", naturally, belongs in TYPE t_person
and not elsewhere.
> Also, it is my understanding that INTENT is supposed to be a hint to
> the compiler and something which the programmer is responsible for
> ensuring the proper use of; the compiler isn't required, AFAIK, to
> diagnose misuse of an INTENT, or even to make use of your specified
> INTENT in any way. It's just that if it can find a way to make an
If the purpose of INTENT is only to aid optimizations and it is
entirely users responsibility to ensure its correct usage, I am really
unaware of any F90 textbook or tutorial notes on the web that
discusses this issue in detail. Pls. refer me to a textbook that
describes this in detail.
I hope I have made things little bit more clear this time.
And thanks again,
--
Hari Sundararaghavan, | Email: [log in to unmask]
Ph. D. Student, Ocean Engineering, | [log in to unmask]
University of Hawaii at Manoa. | Ph:(808)-956-8198 FAX:(808)-956-3498
--------------------------------------------------------------------------
Visit my home page at <URL:http://oceaneng.eng.hawaii.edu/~sharik>
--------------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
