|
|
 Up |
|
|
  |
Author: Walter SpectorWalter Spector Date: Apr 27, 2008 06:48
Fellow clfers,
Consider the following:
subroutine commonptr ()
implicit none
type wws_t ! No SEQUENCE and has default initialization
integer :: x = 1, y = 2, z = 3
end type
type (wws_t), pointer :: my_wwsptr
common /block/ my_wwsptr
allocate (my_wwsptr)
my_wwsptr = wws_t (3, 4, 5)
end subroutine
We all know that for a derived type object to reside in COMMON, it
must have a SEQUENCE attribue, and must not have default initialization
specified. These are documented in constraint C589 in § 5.5.2 of F2003:
"C589 (R558) If a common-block-object is of a derived type, it shall be
a sequence type or a type with the BIND attribute and it shall have no
default inititialization."
|
| Show full article (1.05Kb) |
|
| | 4 Comments |
|
|
Author: Tobias BurnusTobias Burnus Date: Apr 27, 2008 09:00
On Apr 27, 3:48 pm, Walter Spector earthlink.net>
wrote:> type wws_t ! No SEQUENCE and has default initialization
> integer :: x = 1, y = 2, z = 3
> end type
> type (wws_t), pointer :: my_wwsptr
> common /block/ my_wwsptr
As follow up question: What if there is a SEQUENCE attribute? Is this
then valid or not? (The default initializer does not get applied to
the pointer, only to its target. Thus there is no reason why it should
be invalid --- unless C589 does not allow it.)
> "C589 (R558) If a common-block-object is of a derived type, it shall be
> a sequence type or a type with the BIND attribute and it shall have no
> default inititialization."
>
> But what about *pointers* to the objects? If I merely want to place
> a pointer to the object in the COMMON block, my reading of § 5.5.2
> says that it is legal to allow the pointer regardless.
|
| Show full article (2.16Kb) |
|
| | no comments |
|
|
Author: Walter SpectorWalter Spector Date: Apr 27, 2008 11:42
Tobias Burnus wrote:
> On Apr 27, 3:48 pm, Walter Spector earthlink.net>
> wrote:>> type wws_t ! No SEQUENCE and has default initialization
>> integer :: x = 1, y = 2, z = 3
>> end type
>> type (wws_t), pointer :: my_wwsptr
>> common /block/ my_wwsptr
>
>
> As follow up question: What if there is a SEQUENCE attribute? Is this
> then valid or not? (The default initializer does not get applied to
> the pointer, only to its target. Thus there is no reason why it should
> be invalid --- unless C589 does not allow it.)
It seems to me that default initialization should work, if a derived
type object were used in conjunction with a BLOCK DATA routine.
However I see no verbage allowing it in the Standard. Another wierdness...
In any event, my current concern is with pointers to derived type objects.
|
| Show full article (2.05Kb) |
| no comments |
|
|
Author: nospamnospam Date: Apr 28, 2008 20:29
Walter Spector earthlink.net> wrote:
> Tobias Burnus wrote:
>> On Apr 27, 3:48 pm, Walter Spector earthlink.net>
>> wrote:>>> "C589 (R558) If a common-block-object is of a derived type, it shall be
>>> a sequence type or a type with the BIND attribute and it shall have no
>>> default inititialization."
>>>
>>> But what about *pointers* to the objects? If I merely want to place
>>> a pointer to the object in the COMMON block, my reading of § 5.5.2
>>> says that it is legal to allow the pointer regardless. >>
>> Contrary to you, my reading is that this applies also to a pointer to
>> a derived type.
>
> I can read it either way,
|
| Show full article (2.74Kb) |
| no comments |
|
|
|
|
|
Author: Walter SpectorWalter Spector Date: Apr 30, 2008 14:36
Richard Maine wrote:
> ...
> If you try to read such words any other way, I think you'll find that
> large parts of the standard fall apart - at least if one tries to apply
> the same reading throughout the standard...
Thank you Richard, I was afraid of that!
> Now as to why the restriction is that broad, that is harder to answer...
I wonder if anyone ever gave it much thought.
An easy way to muck with innards of an F90 pointer is to put it (or a copy
of it) in a COMMON block. But the generality of this approach is ruined because
only a subset of pointers are allowed to reside in COMMON.
It seems to me that the pointers should be allowed. Perhaps, as you say,
the single word "nonpointer" could be added to the constraint.
W.
|
| |
| no comments |
|
|
