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

ALLOCATABLE or POINTER


I would like to know whether a pointer array could replace and
allocatable dummy argument.

Here is an example :

MODULE alloptr

  INTERFACE foo
    MODULE PROCEDURE fooalloc
    !MODULE PROCEDURE fooalloc,fooptr ! the instruction for the second
test
  END INTERFACE

  CONTAINS

  SUBROUTINE fooalloc(a)
    INTEGER,ALLOCATABLE,INTENT(out) :: a(:)
    ALLOCATE(a(10))
    a(:)=1
  END SUBROUTINE

  SUBROUTINE fooptr(a)
    INTEGER,POINTER :: a(:)
    ALLOCATE(a(10))
    a(:)=1
  END SUBROUTINE

  SUBROUTINE test
    INTEGER,ALLOCATABLE :: a1(:)
    INTEGER,POINTER     :: a2(:)
    CALL foo(a1)
    write(*,*) a1
    CALL foo(a2)
    write(*,*) a2
  END SUBROUTINE
END MODULE

PROGRAM test11
  USE alloptr
  CALL test
END PROGRAM

In this example, the  routine foo is declared as receiving an
ALLOCATABLE argument. When passing a pointer array instead, the result
depends on the compiler and even the version of the compiler :

- g95 0.91 (May 20 2007) : OK
- ifort 9.0 : OK
- lf95 : error
- ifort 9.1 : error
- Sun f90 : error

When an error occurs, then the compiler indicates that the second call
to "foo" is wrong because the argument is not an ALLOCATABLE array.

For these compilers, I decided to modify slightly the example, addiing
"fooptr" as another alternative for "foo". But the result is the
following :

- g95 0.91 (May 20 2007) : error
- ifort 9.0 : error
- lf95 : warning
- ifort 9.1 : error
- Sun f90 : error

For compilers which do not mention any error for the first test, I
understand : ambiguous interface. But for the other ones, how the
interface could be ambiguous when they declared an error in the first
test ????

Only lf95 is "rather" logical : it just produces a warning (why ?) but
the second test runs correctly.

So what is the correct programming ? From my point of view, a pointer
array should be able to "replace" an allocatable dummy argument (as it
may "replace" any array argument).

On 21 mei, 11:34, fj <francois.j@irsn.fr> wrote:

In Fortran 90/95 dummy arguments can not be allocatable,
though there is a technical report (official compiler extension
as it were) that describes how they can be. Many compilers
implement this, but not all.

I am not quite sure if the pointer attribute is used to disambiguate
the interface "foo", but it may be that you
have to remove "fooalloc" in your second test.

Regards,

Arjen

"fj" <francois.j@irsn.fr> wrote in message

news:1179740082.643348.156740@x18g2000prd.googlegroups.com...
>I would like to know whether a pointer array could replace an
> allocatable dummy argument.

Yes, but not in the way you have shown in your test. Firstly, whether a
dummy argument has the pointer or allocatable attribute is not an allowed
means whereby it is possible to disambiguate a generic reference (MR&C,
Section 5.18). Secondly, a pointer dummy argument must correspond to a
pointer actual argument (op. cit., Section 5.7.1)

Regards,

Mike Metcalf

On 21 mai, 14:11, "Michael Metcalf" <michaelmetc@compuserve.com>
wrote:

> "fj" <francois.j@irsn.fr> wrote in message

> news:1179740082.643348.156740@x18g2000prd.googlegroups.com...>I would like to know whether a pointer array could replace an
> > allocatable dummy argument.

> Yes, but not in the way you have shown in your test. Firstly, whether a
> dummy argument has the pointer or allocatable attribute is not an allowed
> means whereby it is possible to disambiguate a generic reference (MR&C,
> Section 5.18). Secondly, a pointer dummy argument must correspond to a
> pointer actual argument (op. cit., Section 5.7.1)

> Regards,

> Mike Metcalf

I think that my first test case respects both conditions :
- the routine "foo" (fooalloc) has a single signature (no need to
disambiguate a generic reference)
- the dummy argument is not a pointer but an allocatable array. So the
actual argument maybe either a pointer to an array or an allocatable
array.

So I conclude that g95 and ifort9.0 are following F2003 requirements
whereas other compilers have a strange behaviour : they should simply
refuse the ALLOCATABLE parameter for a dummy argument.

Regards

F. Jacq

"fj" <francois.j@irsn.fr> wrote in message

news:1179759390.378104.295360@z28g2000prd.googlegroups.com...
> I think that my first test case respects both conditions :
> - the routine "foo" (fooalloc) has a single signature (no need to
> disambiguate a generic reference)
> - the dummy argument is not a pointer but an allocatable array. So the
> actual argument maybe either a pointer to an array or an allocatable
> array.

Yes, but of course footest calls fooalloc twice. Your second version cannot
work.

> So I conclude that g95 and ifort9.0 are following F2003 requirements
> whereas other compilers have a strange behaviour : they should simply
> refuse the ALLOCATABLE parameter for a dummy argument.

As Arjen pointed out (and I forgot to mention), most but not all compilers
have implemented allocatable dummy arguments (it's a standardized extension
to f95, not simply a part of f2003).

Regards,

Mike Metcalf

fj <francois.j@irsn.fr> wrote:
> - the dummy argument is not a pointer but an allocatable array. So the
> actual argument maybe either a pointer to an array or an allocatable
> array.

That conclusion is false. If the dummy argument is an allocatable, the
allocatable argument must be an allocatable; it may not be a pointer.

Second, as MIke said, you do have an illegal generic in the version
where you mentioned that you have both fooalloc and fooptr

> So I conclude that g95 and ifort9.0 are following F2003 requirements
> whereas other compilers have a strange behaviour : they should simply
> refuse the ALLOCATABLE parameter for a dummy argument.

I can't parse what you mean by that. There is nothing wrong in f2003
with having an allocatable dummy argument (not "parameter" - that means
something unrelated in Fortran). As Mike said, your code has two
problems - using a pointer actual argument for an allocatable dummy, and
using allocatable vs pointer to disambiguate. I see both problems in the
code (one in each version of teh code that you mention).

Note that the standard doesn't require that neither of these errors be
diagnosed by the compiler, though I'd think it good if compilers did
diagnose them.

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

 > As Mike said, your code has two problems - using a pointer actual argument
 > for an allocatable dummy, and using allocatable vs pointer to disambiguate.
 > [...] Note that the standard doesn't require that neither of these errors be
 > diagnosed by the compiler, though I'd think it good if compilers did
 > diagnose them.

I find that statement confusing. I can understand that a compiler would find
it impossible to diagnose the first case when seperate compilation without
explicit interfaces (or a lying explicit interface) is being used. But for the
second case, as the actual routine to be called needs to be resolved at
compile time (yes, I know the standard doesn't use these terms), how can the
compiler _not_ diagnose this particular problem?

        Jan

Richard Maine wrote:
> fj <francois.j@irsn.fr> wrote:
>>- the dummy argument is not a pointer but an allocatable array. So the
>>actual argument maybe either a pointer to an array or an allocatable
>>array.
> That conclusion is false. If the dummy argument is an allocatable, the
> allocatable argument must be an allocatable; it may not be a pointer.

It is possible that on some implementations they are the same
or similar, and that it will work, or seem to work.

As a general rule, if something happens to work on one implementation,
that doesn't make it standard conforming.

-- glen

Jan Vorbrggen <jvorbrueg@not-mediasec.de> wrote:
>  > As Mike said, your code has two problems - using a pointer actual
>  > argument for an allocatable dummy, and using allocatable vs pointer to
>  > disambiguate. [...] Note that the standard doesn't require that neither
>  > of these errors be diagnosed by the compiler, though I'd think it good
>  > if compilers did diagnose them.

> I find that statement confusing. I can understand that a compiler would find
> it impossible to diagnose the first case when seperate compilation without
> explicit interfaces (or a lying explicit interface) is being used. But for the
> second case, as the actual routine to be called needs to be resolved at
> compile time (yes, I know the standard doesn't use these terms), how can the
> compiler _not_ diagnose this particular problem?

Well, for a start, it could allow it as an extension. In fact, there was
serious discussion of putting an extension like that in the standard. I
forget whether or not that proposal is still "alive", but it did get at
least serious consideration.

I didn't say the compiler couldn't disgnose it - that it was imossible
or even necessarily difficult. I just said that the standard didn't
require such diagnosis. And if the compiler allows disambiguation by
allocatable/pointer, then it would make sense to have no error message
(unless one specifically requested standard conformance checking).

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

In article <5bdv4aF2s6cm@mid.individual.net>,
Jan Vorbrggen  <jvorbrueg@not-mediasec.de> wrote:

>How can the compiler _not_ diagnose this particular problem?

The rule is that compilers are required to diagnose problems in a
program if and only if they violate Constraints in the Fortran
standard. A compiler is free to do anything at all (except a compile-
time crash and core dump) with a program that violates the standard in
a way that does not violate any Constraint.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

>>How can the compiler _not_ diagnose this particular problem?
> The rule is that compilers are required to diagnose problems in a
> program if and only if they violate Constraints in the Fortran
> standard. A compiler is free to do anything at all (except a compile-
> time crash and core dump) with a program that violates the standard in
> a way that does not violate any Constraint.

Yeah, I know that. I'd say I really wanted to ask a slightly different
question: Given that the processor (if not supporting it as an extension)
needs to diagnose this at compile time, and that constraints are (informally)
put into the standard if they can be enforced at compile time, why didn't this
one get a constraint in the standard?

        Jan

On 21 mai, 17:17, nos@see.signature (Richard Maine) wrote:

> fj <francois.j@irsn.fr> wrote:
> > - the dummy argument is not a pointer but an allocatable array. So the
> > actual argument maybe either a pointer to an array or an allocatable
> > array.

> That conclusion is false. If the dummy argument is an allocatable, the
> allocatable argument must be an allocatable; it may not be a pointer.

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

So, I have a second question : how to program a valid procedure
interface (in F2003) which allows an actual argument to be either a
pointer to an array or an allocatable array ? This was the goal of my
two first attempts !

Considering M. Metcalf's remarks, he seems to think that my first test
could be the solution. But R. Maine's conclusions are that the two
solutions I proposed are wrong. Is my request really impossible ???

F. Jacq

On May 22, 9:10 am, fj <francois.j@irsn.fr> wrote:

Fortran (yes, even F2003) uses TKR (type, kind, rank) in
disambiguating procedure interfaces - two dummy arguments are
considered distinct if they are TKR incompatible - no other attributes
count, nor does the character length, or assumed shape/explicit shape/
assumed size, or whatever else.
The standard sacrificed power for simplicity here (as in many other
places). It could be technically possible to select between
REAL,ALLOCATABLE:: a(:) and REAL,POINTER:: a(:), but not between on of
them and REAL:: a(:). That would further complicate the rules for
generic interfaces.
Note that you can work-around this (in F95+TR15581) by defining your
own types:
type real_al
  real,allocatable:: x(:)
end type
type real_po
  real,pointer:: x(:)
end type
and use these to disambiguate interfaces.

fj <francois.j@irsn.fr> wrote:
> So, I have a second question : how to program a valid procedure
> interface (in F2003) which allows an actual argument to be either a
> pointer to an array or an allocatable array ? This was the goal of my
> two first attempts !

It can't be done.

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

On 22 mai, 17:12, nos@see.signature (Richard Maine) wrote:

> fj <francois.j@irsn.fr> wrote:
> > So, I have a second question : how to program a valid procedure
> > interface (in F2003) which allows an actual argument to be either a
> > pointer to an array or an allocatable array ? This was the goal of my
> > two first attempts !

> It can't be done.

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

Just a last question : why ?

>From my point of view, all the rules of a programming language should

be clearly understandable and compatible together because I am just a
programmer and not an expert in language specifications : I want to be
able to decide in few seconds if a new programming technique will
probably (surely) work.

Here, I think that any Fortran programmer understands why it is
possible to replace a dummy normal argument either by a actual pointer
variable (of course associated) or an actual allocatable variable (of
course allocated) : a pointer or an allocatable variable has
potentially more "power" than a normal variable. And of course, the
programmer also understands why te reverse operation is forbidden.

In the same way, I think that a pointer variable has potentially more
"power" than an allocatable variable. Like an allocatable, it can be
allocated but, in addition, it can been associated (pointing to any
memory area already allocated). So again, replacing an allocatable
dummy argument by an actual pointer variable seems correct (like in my
first attempt).

Now you explain that this is wrong : an allocatable variable must fit
a dummy allocatable argument and a pointer variable must fit a pointer
dummer argument. OK, this could be a simple rule I can remember. But
in that case, I see a contradiction with the rule TKR : the compiler
must now distinguish ALLOCATABLE and POINTER dummy arguments (like in
my second attempt) else the coherence of rules is lost.

Of course I prefer my first attempt (this is why I programmed it
first).

For me, the limitation "allocatable with allocatable" looks like the
limitations "no charcacter variable inside a common containaing
numerical variables" (is this old F77 rule always true ?)  or "no
equivalence between characters and numbers". I never accepted them.
And of course (I don't know why), this is the first thing I tested
(without success) when learning F77 (before having reading the rules).
Probably, I like the "border line" programming. O course, I learnt
later that this was mainly due to a problem of memory alignment ...
But this is an implementation dependent reason. As it exists
implementations making possible to equaivalencing characters and
numbers, such reason looks bad.

> Just a last question : why ?

> >From my point of view, all the rules of a programming language should

> be clearly understandable and compatible together because I am just a
> programmer and not an expert in language specifications : I want to be
> able to decide in few seconds if a new programming technique will
> probably (surely) work.

They are (at least in this case). Only TKR incompatibility of dummy
arguments disambiguates interfaces. End of story.

> Here, I think that any Fortran programmer understands why it is
> possible to replace a dummy normal argument either by a actual pointer
> variable (of course associated) or an actual allocatable variable (of
> course allocated) : a pointer or an allocatable variable has
> potentially more "power" than a normal variable. And of course, the
> programmer also understands why te reverse operation is forbidden.

> In the same way, I think that a pointer variable has potentially more
> "power" than an allocatable variable. Like an allocatable, it can be
> allocated but, in addition, it can been associated (pointing to any
> memory area already allocated). So again, replacing an allocatable
> dummy argument by an actual pointer variable seems correct (like in my
> first attempt).

It is simply not true in Fortran that ALLOCATABLEs are compatible with
POINTERs. They are different concepts - an allocatable is allocated, a
pointer is associated. If you use ALLOCATE what pointer, the standard
says that an anonymous object with implicit TARGET attribute is
created and the pointer is associated with it.
The difference is quite clear - nothing in the standard merely
suggests that a POINTER could be substituted for an ALLOCATABLE. Note
that ALLOCATED only works on ALLOCATABLEs and ASSOCIATED only works on
POINTERs.

> Now you explain that this is wrong : an allocatable variable must fit
> a dummy allocatable argument and a pointer variable must fit a pointer
> dummer argument. OK, this could be a simple rule I can remember. But
> in that case, I see a contradiction with the rule TKR : the compiler
> must now distinguish ALLOCATABLE and POINTER dummy arguments (like in
> my second attempt) else the coherence of rules is lost.

There is no contradiction. You probably implicitly assume that
if two argument specifications don't disambiguate, they must be call-
compatible. This is not true. The language is simply not stretched to
a maximum here. I won't go into a discussion whether this is good or
wrong.

A compiler may implement ALLOCATABLES so that they're compatible with
POINTERs, however, the standard does not require this. The ALLOCATABLE
descriptors theoretically need not carry strides; OTOH, they can carry
additional information used for optimizations or for ensuring
automatic deallocations. Thus, the descriptors can be incompatible.

>>>So, I have a second question : how to program a valid procedure
>>>interface (in F2003) which allows an actual argument to be either a
>>>pointer to an array or an allocatable array ? This was the goal of my
>>>two first attempts !

>>It can't be done.

> Just a last question : why ?

[snipped reasoning of why it should be possible]

Implementation is one aspect, and this has always been a strong argument in
the standardization process (for good and for bad). But there is a more
fundamental one: The set of operations you can perform, and their semantics,
are different for (1) a pointer, (2) an allocatable, or (3) a POV (plain old
variable) - let's ignore the "array or scalar" aspect for the moment, as it is
only marginally relevant.

For instance, the allocatable has the semantics that there is only ever one
reference to it (unless it has been TARGETted). You ask an allocatable whether
it is ALLOCATED and a pointer whether it is ASSOCIATED. The semantics of, in
particular, INTENT(OUT) allocatable dummy arguments are different from
anything else. And so on.

I think if you were to do the analysis, it would show that it is impossible to
allow a an allocatable dummy to be associated with a pointer actual without
potentially breaking the semantics of both.

        Jan

On 23 mai, 11:18, Jan Vorbrggen <jvorbrueg@not-mediasec.de> wrote:

I understand your arguments but I don't agree with them. The
differences are too subtle for a "standard" programmer like me. Of
course you must use ASSOCIATED with a pointer and not ALLOCATED
because a pointer can be something different from an allocatable. But
because a pointer may be also allocated in the same way as an
allocatable, then it should be possible, in some circumstances to
replace an allocatable by a pointer. If the implementation of a
pointer does not match the implementation of the allocatable, then the
compiler should do the translation (copy in/out for instance).

With the same arguments we could exclude the possibility to pass a
pointer by argument when the dummy argument is a standard variable ...
because a pointer and a standard variable have not the same
implementation and because they do not represent the same concept.

I tried to read the specifications of the F95 extension for allocated
dummy arguments. Not easy to understand all. But I am sure that in
changing two words, no more, the "extension" I proposed would be
specified ;-)

OK I stop here the discussion. I just keep the conclusion of R.
Maine : "It can't be done".

On 23 mai, 11:18, Jan Vorbrggen <jvorbrueg@not-mediasec.de> wrote:

I understand your arguments but I don't agree with them. The
differences are too subtle for a "standard" programmer like me. Of
course you must use ASSOCIATED with a pointer and not ALLOCATED
because a pointer can be something different from an allocatable. But
because a pointer may be also allocated in the same way as an
allocatable, then it should be possible, in some circumstances to
replace an allocatable by a pointer. If the implementation of a
pointer does not match the implementation of the allocatable, then the
compiler should do the translation (copy in/out for instance).

With the same arguments we could exclude the possibility to pass a
pointer by argument when the dummy argument is a standard variable ...
because a pointer and a standard variable have not the same
implementation and because they do not represent the same concept.

I tried to read the specifications of the F95 extension for allocated
dummy arguments. Not easy to understand all. But I am sure that in
changing two words, no more, the "extension" I proposed would be
specified ;-)

OK I stop here the discussion. I just keep the conclusion of R.
Maine : "It can't be done".

> With the same arguments we could exclude the possibility to pass a
> pointer by argument when the dummy argument is a standard variable ...
> because a pointer and a standard variable have not the same
> implementation and because they do not represent the same concept.

In this case, the caller knows (or assumes) the callee's requirements with
regard to interfacing, and can adapt accordingly. The case we are discussing,
however, requires knowledge about what the callee is actually doing with the
associated actual argument, and there is no standard-conforming - or even
easily-conceivable - way to tell the caller about this.

        Jan

On 23 mai, 14:55, Jan Vorbrggen <jvorbrueg@not-mediasec.de> wrote:

> > With the same arguments we could exclude the possibility to pass a
> > pointer by argument when the dummy argument is a standard variable ...
> > because a pointer and a standard variable have not the same
> > implementation and because they do not represent the same concept.

> In this case, the caller knows (or assumes) the callee's requirements with
> regard to interfacing, and can adapt accordingly. The case we are discussing,
> however, requires knowledge about what the callee is actually doing with the
> associated actual argument, and there is no standard-conforming - or even
> easily-conceivable - way to tell the caller about this.

>         Jan

I am sorry but again I don't understand. The called routine cannot do
so many things with an allocatable argument and all these things are
well specified by the corresponding F95 specification extension.

- the called routine requirement is clear : it expects an allocatable
variable and it may use it (if already allocated), allocate it (if not
allocated before), deallocate it (if already allocated) or reallocate
it (after deallocating it if it is already allocated).
- the caller, trying to pass a pointer rather than an allocatable,
knows that (via interface) and has to transfer the pointer itself if
the implementations of pointer and allocatable match, or an
intermediate allocatable value, unallocated if the pointer is not
associated else allocated and initialized correctly.
- if the called routine deallocates the argument, then of course, the
pointer needs to be associated to an allocatable array. If not, then a
run-time error should issue : here this is simply a programmer
mistake, as passing to a dummy normal argument an non associated
pointer for instance.

So I don't see what is not easily-conceivable

F. Jacq

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