having trouble running generic linked list program

having trouble running generic linked list program

I have a small test program which creates a generic linked list.   It compiles, but doesn't run.

When I try to access the values of the link, it gets a memory error (access violation).

The values of the list are pointers to unlimited polymorphic variables.

I have attached the code.

Can you tell me what I'm doing wrong?

Thanks

AttachmentSize
Downloadapplication/octet-stream generic_linklist.f90691 bytes
Downloadapplication/octet-stream link.f901.84 KB
Downloadapplication/octet-stream list_0.f902.39 KB
8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hello Terry,

I think in link.f90, instead of:

  type link
    !private
    class(*), pointer :: value => null()
    type(link), pointer :: next => null()

you should first define 'next' as:

  type link
    !private
    class(*), pointer :: value => null()
    class(link), pointer :: next => null()
 

Otherwise, you will have conflicting pointer type assignments at line 31 (constructor%next => next) and line 44 ( this%next => next), ie, you would attempting to assign CLASS(link) to TYPE(link).
 

I made that change, and the code compiled and linked, but the executable crashed at line 56 in link.f90, on the select type:

    subroutine printLink(this)
      implicit none
      class(link) :: this
      select type(v => this%value)

I don't know if this is a compiler bug or not.  I'll need to work through the traceback.  I suspect something funny about line 59:

     type is (character(*))

I think this is legal, but I'll need to look into it.

Thank you,

Patrick
 

Hello Terry,

The access violation is due to a bug in link.f90, subroutine printLinks. 

On first entry, 'curr' is unassociated. 

If you comment out the call to printLink (as shown), the program runs normally.

    subroutine printLinks(this)
    implicit none
    class(link) :: this
    class(link), pointer :: curr

!!!    call printLink(curr)
    curr => this%next
    do while(associated(curr))
      call printLink(curr)
      curr => curr%next
    enddo

With that change, things seem normal:

>ifort link.f90 list_0.f90 generic_linklist.f90 -Fe:foo.exe

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.176 Build 20140130
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:foo.exe
-subsystem:console
link.obj
list_0.obj
generic_linklist.obj

>foo
           2
           3
           4
           5
           6
           7
           8
           9
          10
   1.230000
 A
 B

Is that the correct output?

Thanks,

Patrick

Thanks Patrick, that did fix the problem.

However, I wanted to print the first element as well, so instead of commenting out the first call to printLink, I preceded it with curr=>this, or I could have used printLink(this).

One comment, I can't see the value variable in the debugger.  Is this because it is a unlimited polymorphic variable?

Hi Terry,

I don't know of a restriction viewing  class(*) variables in the debugger.  Could you be more specific?  For example, using VS2012, in subroutine addInteger(this, value), I set a breakpoint on the allocate statement at line 56:

allocate(v,source=value) !! line 56

With a Debug x64 configuation, I can repeatedly run to that breakpoint and see 'value' updated with every pass:
U506813.exe!LIST_MOD_mp_ADDINTEGER(TYPE(LIST) THIS={...} , INTEGER(4)  VALUE=#00000004 ) Line 56 Unknown

What do you see?

Thanks,

Patrick
 

Yes, I can see the what the variable value contains, but after I allocate v, I cannot see what v contains.

Also, when I am looping through prinkLink, the debugger cannot show me the value of v or this%value.

I am using the debugger in 64 bit mode.

Thanks for looking at it.

 

Terry

A class(*) variable has no type on its own - you need to be within a SELECT TYPE construct and then a new "copy" of the variable will be visible in the debugger and you can see its contents as if it were the selected type.

Retired 12/31/2016

Hi Terry,

Thanks for the feedback.  Right, I can't see the value of the associate-name variable (ie, the 'v') nor the value of this%value in PrintLink().  You might have run into a limitation of the Fortran Expression Evaluator (FEE).  I'll ask the developers.

Patrick

Leave a Comment

Please sign in to add a comment. Not a member? Join today