Re: compilation problem with module function interface definition

Richard E Maine wrote: 
In article <R_Cbe.8734$Bc7.2299@xxxxxxxxxxxxxxxxxxxx>,
 Phony Account <phaccount@xxxxxxxxxxxx> wrote:


Other than lack of fortran95/03 knowledge, what other cardinal rule of the modern fortran language is the following snippet breaking?

The module compiles cleanly with the interface block commented out. If I include it, ifort complains about type (foo) not being defined. 

.. [all but the most interesting lines elided]

MODULE func_intrfc_test
  type foo
  end type foo

!!$INTERFACE test_generic
!!$   real FUNCTION test_particular(obj,arg) RESULT(result)
!!$     type(foo) obj
!!$     real,intent(in)::arg
!!$   end FUNCTION test_particular
!!$END INTERFACE

CONTAINS
  real FUNCTION test_particular(obj,arg) RESULT(result)


As a Donald nicely exposed, the other cardinal rule that I broke (I have the f95/03 explained book) is lack of reading and comprehension skills. I re-read Section 5.18 with care, and sure enough it all makes sense now.

Moving on to Richard E Main's note, I need to come out clean and expose the ``dirty laundry'' regarding the reason as to why I wanted to re-define the function interface.

... Richard's note deleted.

My experience in OOP comes from the IDL programming language (see www.rsinc.com) where objects are brought into existence thus:

oFoo=create_obj("object name", argument list ...)

I was trying to mimick this behavior by
- declaring an object type:
    > type (class) obj
- and bringing it into existence:
   > obj=create_obj(argument list)

where in the class definition (module) I would have (a full example is included below):

interface create_obj
   module procedure create_obj_foo
end interface

contains

function create_obj_foo(args) result (obj)
type (class) obj

end function
end module

This works if I have only one class that I am trying instantiate, but not if I have more than one and the instantiation procedure has arguments of identical type. Here is a listing of two modules and of a main program.

MODULE O1

  type O1_class
     integer foo
  end type O1_class

  interface create_obj
     module procedure create_obj1
  end interface

CONTAINS

    FUNCTION create_obj1(param)  RESULT(obj)

    ![function_header_comments]
    type (O1_class) obj
    integer,intent(in)::param

    obj%foo=param

  END FUNCTION create_obj1

END MODULE O1


MODULE O2

![module_header_comments]
  type O2_class
     real fee
  end type O2_class

  interface create_obj
     module procedure create_obj2
  end interface

CONTAINS
    FUNCTION create_obj2(param)  RESULT(obj)

    ![function_header_comments]
    type (O2_class) obj
    integer,intent(in)::param

    obj%fee=param

    RETURN
  END FUNCTION create_obj2

END MODULE O2


PROGRAM O12_test

![main_header_comments]
use O1
use O2

type (O1_class) o1_obj
type (O2_class) o2_obj

o1_obj=create_obj(5)
o2_obj=create_obj(10)

print *,o1_obj%foo,o2_obj%fee

END PROGRAM O12_test

The compilation of O12_test fails because the arguments to the two "new_obj" are identical. I was hoping that the compiler will be able to distinguish between the two functions based on the result type. But I guess not. It looks only at the arguments types, which in this case are identical.


This failure is not a show-stopper. Instead of functions, I can use appropriately defined subroutines and their interfaces:

call create_obj(o1_obj,5)


But I wonder as to the reason why the compiler does not include the function type when dealing resolving polymorphisms? Maybe because the result is not allways assigned to a typed variable. This could be dealt with with a more obscure invocation of the function which would also specify the desired result type. But that is a completely different thread.

Thanks,

Mirko
.

Relevant Pages

  • Re: ALLOCATABLE or POINTER
    ... INTERFACE foo ... !MODULE PROCEDURE fooalloc,fooptr! ... depends on the compiler and even the version of the compiler: ... understand: ambiguous interface. ...
    (comp.lang.fortran)
  • Re: Use of interface within module?
    ... Should the interface be used within the ... -| subroutine plot_a ... The interface block is required so that the compiler can ... -|so the module procedure statement suffices in this case. ...
    (comp.lang.fortran)
  • Re: why doesnt this compile ?
    ... You either have an interface body or use a module procedure statement. ... If you have a procedure whose interface is already explicit, but which is not a module procedure, then this is awkward. ... "module procedure" in the main program is a compiler *extension*, ...
    (comp.lang.fortran)
  • Re: Proposal: NOEXTERNAL
    ... subroutine differently from what the interface says. ... For modules the compiler spits the dummy when you call your module procedure with an incorrect interface. ... For submodules, the compiler should spit the dummy when it sees that the module interface definition is different from the submodule one. ...
    (comp.lang.fortran)
  • Re: MFC and c++ problems
    ... compiler to generate code that is architecturally nonsensical. ... So a design in which a control has any syntactic knowledge of any container of itself ... GetParent->SendMessage is the interface of choice, ...
    (microsoft.public.vc.mfc)