Prev: Fun with Friedrich Bessel
Next: Invocation of overridden procedure on an abstract parent component
From: Eli Osherovich on 27 Feb 2010 11:12
On Feb 26, 6:36 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:
> "Eli Osherovich" <eli.osherov...(a)gmail.com> wrote in message
>
> news:9a188c46-855f-4284-ad23-8255d0caf90b(a)m37g2000yqf.googlegroups.com...
>
>
>
> > Is there any way to check that a particular function has certain
> > (given) interface.
> > For example, I have a module that contains an abstract interface:
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > module iface
> >  abstract interface
> >     function obj_f(x, flag) result(res)
> >       real :: res
> >       real, intent(in), dimension(2) :: x
> >       real, intent(in), optional :: flag
> >     end function obj_f
> >  end interface
> > end module iface
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > Now, I want to implement a function which has the interface given
> > above. Of course, there is no problem to implement it. However, I
> > would like a complier to check that the interface is indeed what I
> > expect.
>
> C:\gfortran\clf\ifacechk>type ifacechk.f90
> module iface
>   abstract interface
>      function obj_f(x, flag) result(res)
>        real :: res
>        real, intent(in), dimension(2) :: x
>        real, intent(in), optional :: flag
>      end function obj_f
>   end interface
>
> end module iface
>
> function test(x)
>    use iface
>    implicit none
>    real, intent(in) :: x(2)
>    real test
>    procedure(obj_f), pointer :: testp
>
>    if(.FALSE.) testp => test
> end function test
> C:\gfortran\clf\ifacechk>gfortran -c -Wall ifacechk.f90
> ifacechk.f90:19.24:
>
>    if(.FALSE.) testp => test
>                         1
> Error: Interface mismatch in procedure pointer assignment at (1): 'test' has
> the
>  wrong number of arguments
>
> --
> write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
> 6.0134700243160014d-154/),(/'x'/)); end

It is interesting, however, it is not what I am looking for.

I should probably explain the purpose of such a check in the very
beginning.

The idea was to provide an interface for writing plugins for a bigger
system.

Such a plugin has a well defined interface. Of course, I can provide
the interface and hope that every plugin writer will write his plugins
exactly as expected.

For obvious reasons, it would be very nice if any interface mismatches
could be identified at the compilation stage.

Thank you.
From: Richard Maine on 27 Feb 2010 11:52
Eli Osherovich <eli.osherovich(a)gmail.com> wrote:

> The idea was to provide an interface for writing plugins for a bigger
> system.
>
> Such a plugin has a well defined interface. Of course, I can provide
> the interface and hope that every plugin writer will write his plugins
> exactly as expected.
>
> For obvious reasons, it would be very nice if any interface mismatches
> could be identified at the compilation stage.

You might want to look at the submodule feature, which was introduced in
a TR to f2003. In my estimation, such plugins fit very well with
implementation via submodules. In short, you first write the main
module, which specifies the interface for the plugin. Then a submodule
provides the implementation of the plugin.

This has multiple advantages, which I see as arising from the
dependencies going in the "right" direction for such plugins. You write
the interface first in the main module. The plugin in the submodule then
depends on the interface instead of the other way around. Without this
feature, one tends to find that the writer of a plugin has to recompile
the whole application (or anyway much of it) instead of being abble to
link with a precompiled library version.

I don't think the standard makes it mandatory that the interface be
checked (I didn't see such a requirement in quick skim), but I would
expect compilers to do so as a matter of course.

I don't know whether the compilers of relevance to you yet support the
feature, however.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Eli Osherovich on 27 Feb 2010 13:31
On Feb 27, 6:52 pm, nos...(a)see.signature (Richard Maine) wrote:
> Eli Osherovich <eli.osherov...(a)gmail.com> wrote:
> > The idea was to provide an interface for writing plugins for a bigger
> > system.
>
> > Such a plugin has a well defined interface. Of course, I can provide
> > the interface and hope that every plugin writer will write his plugins
> > exactly as expected.
>
> > For obvious reasons, it would be very nice if any interface mismatches
> > could be identified at the compilation stage.
>
> You might want to look at the submodule feature, which was introduced in
> a TR to f2003. In my estimation, such plugins fit very well with
> implementation via submodules. In short, you first write the main
> module, which specifies the interface for the plugin. Then a submodule
> provides the implementation of the plugin.
>
> This has multiple advantages, which I see as arising from the
> dependencies going in the "right" direction for such plugins. You write
> the interface first in the main module. The plugin in the submodule then
> depends on the interface instead of the other way around. Without this
> feature, one tends to find that the writer of a plugin has to recompile
> the whole application (or anyway much of it) instead of being abble to
> link with a precompiled library version.
>
> I don't think the standard makes it mandatory that the interface be
> checked (I didn't see such a requirement in  quick skim), but I would
> expect compilers to do so as a matter of course.
>
> I don't know whether the compilers of relevance to you yet support the
> feature, however.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

Richard thank you very much for pointing to submodules.
The idea looks very good. Unfortunately neither Intel Fortran nor
gfortran provide this feature.

From: James Van Buskirk on 27 Feb 2010 15:44
"Eli Osherovich" <eli.osherovich(a)gmail.com> wrote in message
news:469707f3-c6a1-4fa0-9ae7-9bddc8d9d8a3(a)15g2000yqa.googlegroups.com...

> It is interesting, however, it is not what I am looking for.

> I should probably explain the purpose of such a check in the very
> beginning.

> The idea was to provide an interface for writing plugins for a bigger
> system.

> Such a plugin has a well defined interface. Of course, I can provide
> the interface and hope that every plugin writer will write his plugins
> exactly as expected.

> For obvious reasons, it would be very nice if any interface mismatches
> could be identified at the compilation stage.

Obviously, you aren't even trying to read my responses because my
first example accomplished exactly what you were inquiring about.
However, I provide yet another example for you to reject without
reading...

C:\gfortran\clf\ifacechk>type ifacechk1.f90
module iface
implicit none
abstract interface
function obj_f(x, flag) result(res)
real :: res
real, intent(in), dimension(2) :: x
real, intent(in), optional :: flag
end function obj_f
end interface
end module iface

module plugins
implicit none
contains
function colins_plugin(x)
use iface
implicit none
real, intent(in) :: x(2)
real colins_plugin

colins_plugin = x(1)
end function colins_plugin
end module plugins

program test
use iface
use plugins
use ISO_C_BINDING, only: C_F_PROCPOINTER, C_NULL_FUNPTR
implicit none
procedure(obj_f), pointer :: fpA
procedure(colins_plugin), pointer :: fpB

if(.FALSE.) then
call C_F_PROCPOINTER(C_NULL_FUNPTR,fpA)
fpB => fpA
end if
end program test

C:\gfortran\clf\ifacechk>gfortran -Wall ifacechk1.f90 -oifacechk1
ifacechk1.f90:35.13:

fpB => fpA
1
Error: Interface mismatch in procedure pointer assignment at (1): 'fpa' has
the
wrong number of arguments

Had you read the above code, your problem would have been solved,
but if your problem really is that you want to go to management
with some reason to reject Fortran in an upcoming project, then
you should make try...throw..catch a hard requirement as Fortran
really can't do that, while as has been shown to you it really is
quite good at busting interface mismatches.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: Eli Osherovich on 28 Feb 2010 06:45
On Feb 27, 10:44 pm, "James Van Buskirk" <not_va...(a)comcast.net>
wrote:
> "Eli Osherovich" <eli.osherov...(a)gmail.com> wrote in message
>
> news:469707f3-c6a1-4fa0-9ae7-9bddc8d9d8a3(a)15g2000yqa.googlegroups.com...
>
> > It is interesting, however, it is not what I am looking for.
> > I should probably explain the purpose of such a check in the very
> > beginning.
> > The idea was to provide an interface for writing plugins for a bigger
> > system.
> > Such a plugin has a well defined interface. Of course, I can provide
> > the interface and hope that every plugin writer will write his plugins
> > exactly as expected.
> > For obvious reasons, it would be very nice if any interface mismatches
> > could be identified at the compilation stage.
>
> Obviously, you aren't even trying to read my responses because my
> first example accomplished exactly what you were inquiring about.
> However, I provide yet another example for you to reject without
> reading...


James I appreciate your help.

Your example looks very interesting and I am planning to review it in
depth to see if it is applicable to my situation.
At the first glance it requires me (as a system writer) to compile a
plugin and see if it fits the interface. However, the whole idea was
to remove this step completely.
I want to provide the interface and get back shared libraries that
contain implementation of certain plugins. Of course, a plugin writer
can use your example to check himself I just wanted to automate this
process as much as possible.

P.S.
Your first example gives compilation error when compiler by Intel
compiler (v 11.1). It does not produce any error when compiled by
gfortran (v 4.4.3).
I had to install the latest gfortran snapshot (v 4.5) to see the error
you gave in your post.

Thank you.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Fun with Friedrich Bessel
Next: Invocation of overridden procedure on an abstract parent component