(j3.2006) TYPE(*) and scalars
Bill Long
longb
Wed Mar 21 19:11:25 EDT 2012
On 3/21/12 5:58 PM, Rasmussen, Craig E wrote:
>
> On Mar 21, 2012, at 12:59 PM, Bill Long wrote:
>
>>
>>
>> On 3/21/12 1:35 PM, Bader, Reinhold wrote:
>>> Hello,
>>>
>>>
>>> [...]
>>>>
>>>>
>>>> It should be possible to work around this. If the "known interface
>>>> name" is foo, then
>>>>
>>>> interface foo
>>>> subroutine bar1 (x) bind(C, name="cbar")
>>>> type(*) :: x
>>>> end subroutine bar1
>>>> subroutine bar2 (x) bind(C, name="cbar")
>>>> type(*),dimension(*) :: x
>>>> end subroutine bar2
>>>> end interface
>>>>
>>>> will work. The specifics are distinguishable because of the rank
>>>> distinction, independent of the types. Since you can map both of them
>>>> to the same C routine, there is no need to have extra C wrappers. On
>>>> the C side, the corresponding formal parameter is (void *), which is
>>>> valid for either specific.
>>>
>>> Unfortunately, this will not quite solve the problem, because it now is not possible any more
>>> to process rank 2 and higher arrays - as soon as you put a DIMENSION(*) dummy into a generic
>>> interface, exact rank matching of actual with dummy will be required. I guess one could add
>>> interfaces with
>>>
>>> type(*),dimension(1,*) :: x
>>> type(*),dimension(1,1,*) :: x
>>>
>>
>> OK, but this is unrelated to whether TYPE(*) can be used without using assumed rank. And all of these specifics can map to the same C function. Admittedly, assumed rank is a simpler alternative.
>>
>> Cheers,
>> Bill
>>
>
> Bill,
>
> I don't understand. It seems that you are contradicting Reinhold as he says you can't use a generic interface (as you do in your foo example).
No, Reinhold said ( I think ) that you can use the generic interface if
you do a lot of typing. I'm agreeing with him on that. Both the "can"
and "lot".
> Also the fact that two different procedures have the same binding name seems problematic.
Why? That seems exactly what you need. There is only one of the C
functions in the MPI library that you want to call in each of the cases.
> Suppose you try to implement bar1 and bar2 in Fortran, how does the C programmer have access to either routine?
The point here is that you never actually implement bar1 and bar2. C
programmers would not access these routines - they would take the easy
way and call the C functions directly like they always have.
> Especially since the symbol would have the same name and would lead to a conflict.
>
No conflict. Aleks argued for this capability for some time, and
exactly for this reason.
> I assume it does too much damage to the standard to allow TYPE(*) to take both scalar and array actual arguments?
Completely out of the question for the TS. It is WAAAAAY to late for a
change like this. Apart from it not making sense to begin with.
Cheers,
Bill
> After all a scalar is now just an array of rank 0, yes (I can just hear Malcolm starting to wind up at this point so I'll not say any more :-)
>
> -craig
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3
mailing list