replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Misguided warning 1179?
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Misguided warning 1179?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Mar 11, 2010 11:44 am    Post subject: Misguided warning 1179? Reply with quote

FORTRAN 95 does not allow user-defined types to contain allocatable components, and the workaround is to allow allocation via pointer instead. I have happily been allocating and deallocating derived type components for a while now, but only this morning did I get around to writing code that tested the allocated status of one of them.

The following code provokes (from FTN95 v5.40) warning 1179: - WORKAROUND is not ALLOCATABLE yet is used in an ALLOCATED test.

I think this is wrong, since it is not workaround that is being used in the test, but its allocatable component. Note that the corresponding allocate statement is not flagged as erroneous.

I appreciate its only a warning, and thus non-fatal, but I'd be decidedly happier in ignoring it if other folks who have been doing this new-fangled FTN95 stuff longer than me were in agreement that this warning should not be issued in the first place.

Comments?

<edited immediately post-posting> I hadn't actually tried to run the compiled code when I posted. When I do, I get an access violation on the if (allocated) ... statement.

So clearly there's more to this than meets the eye - mine, anyway. I was wondering whether I have to nullify the pointer before I can test its allocated status? But it can't be that simple - if the component is already allocated, say elsewhere in a module like in my real code, there is no reason why I should not be able to test its allocated status.

Thoughts?

Andy

program hello_kate

type contains_pointer_for_allocation_purposes
integer, pointer :: pseudo_allocatable (Smile
end type contains_pointer_for_allocation_purposes

type (contains_pointer_for_allocation_purposes) workaround

if (allocated (workaround% pseudo_allocatable)) deallocate (workaround% pseudo_allocatable)

allocate (workaround% pseudo_allocatable (10))

stop
end program hello_kate


Last edited by sparge on Thu Mar 11, 2010 12:01 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK

PostPosted: Thu Mar 11, 2010 12:00 pm    Post subject: Reply with quote

I think that you are right. This is a false warning.
Back to top
View user's profile Send private message AIM Address
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Mar 11, 2010 12:02 pm    Post subject: We crossed in the post Reply with quote

Please have a look at my edit while you were replying Smile
Back to top
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK

PostPosted: Thu Mar 11, 2010 12:46 pm    Post subject: Reply with quote

My understanding is that you should nullify the pointer....

Code:
program hello_kate

type contains_pointer_for_allocation_purposes
integer, pointer :: pseudo_allocatable (:) => null()
end type contains_pointer_for_allocation_purposes

type (contains_pointer_for_allocation_purposes) workaround

if (allocated (workaround% pseudo_allocatable)) then
  deallocate (workaround% pseudo_allocatable)
endif 

allocate (workaround% pseudo_allocatable (10))

stop
end program hello_kate
Back to top
View user's profile Send private message AIM Address
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Mar 11, 2010 1:23 pm    Post subject: Reply with quote

Yes, I had come to the same conclusion, but via the nullify statement - even though Metcalf & Reid says nullification allows legitimate testing for disassociation rather than unallocatedness - all as it were.

Use of nullify seems to work, but I don't know why, because syntactically it treats the component as a pointer to an array rather than as an array of pointers.

I can't find any reference to NULL () in M&R "FORTRAN 90 explained" - was it introduced in the transition to FORTRAN 95? I found it in the FTN95 help file, but there it is referred to as an alternative to nullify, still with the purpose of legitimizing testing for disassociation rather than unallocatedness.

Also, I hadn't realised it was possible to assign initial values to components within a type definition - that's pretty wizardly. And the real beauty is it correctly handles the component as an array of pointers.

I love FORTRAN 95.
Back to top
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK

PostPosted: Thu Mar 11, 2010 7:13 pm    Post subject: Reply with quote

Yes I think NULL() is in 95 and not in 90.
Back to top
View user's profile Send private message AIM Address
acw



Joined: 04 Nov 2005
Posts: 165
Location: Darkest Devon

PostPosted: Tue Mar 16, 2010 11:37 am    Post subject: Reply with quote

I didn't think allocated() worked for pointers - I use associated() when dealing with pointers (along with initialisation in the type definition using null()).

My understanding is use associated() for pointers, allocated() for allocatables. Of course being pointers you have to be very careful about nulling them after use if you're going to ever use them again - I always work on the rule that all pointers are initialised to null(), are tested using allocated, and are set to null whenever they are deallocated. Seems to work okay.
Back to top
View user's profile Send private message Visit poster's website
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Mar 16, 2010 1:32 pm    Post subject: Re: Reply with quote

acw wrote:
I didn't think allocated() worked for pointers - I use associated() when dealing with pointers (along with initialisation in the type definition using null()).

My understanding is use associated() for pointers, allocated() for allocatables. Of course being pointers you have to be very careful about nulling them after use if you're going to ever use them again - I always work on the rule that all pointers are initialised to null(), are tested using allocated, and are set to null whenever they are deallocated. Seems to work okay.


I presume you meant "are tested using associated" in the second para, based on what you said in the first?

I understand what you are saying and my reasoning would have been the same - except that given that this particular flavour of pointer is there only to be able to work around the inability to have ALLOCATABLE components in user-defined types, and therefore has to be ALLOCATEd, it seems perverse not to be able to test their ALLOCATED status ... or to put it another way, if:

Code:
allocate (x(n))


is valid code, so should be:

Code:
if (allocated (x(n)))


Testing for ASSOCIATEDness might return .TRUE. or .FALSE. - it depends what's been done since the ALLOCATE - so that can't be the right test?

Andy
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group