Red-Black-Trees and Fortran 2003 Features

Hi,

is there any Fortran 2003 standard conforming way of acquiring  the
address of pointer allocated objects, other than the well-known %loc()
of loc() extensions?

I have a fortran code implementing a red-black-tree-structure which
(until now) uses this extension in order to compare addresses. But my
compiler complains about the F2003 extension. And I am a little bit
pedantic about it...

I know about the c_loc() function from the intrinsic module
iso_c_binding, but this seems to work only with the interoperable typs
(c_int, c_double, ...) from the module and not with self-made
datatypes like this:

type :: rb_node
integer :: color
type(rb_node),pointer :: left,right,parent
real(dp) :: value
end type rb_node

Any ideas?

Cheers,
thorium90

On Aug 20, 12:41 pm, pelot...@gmx.de wrote:

> is there any Fortran 2003 standard conforming way of acquiring  the
> address of pointer allocated objects, other than the well-known %loc()
> of loc() extensions?

Sort of.  The function C_LOC, provided by intrinsic module
ISO_C_BINDING, returns a "C pointer" to its argument, suitable for
passing to a C routine.  The catch is that it comes to you in a value
of type C_PTR which has a private component containing the address.
The intent is for you to declare the interface to C routines as taking
a C_PTR argument.

You can get around this with our old friend TRANSFER.  For example:

use iso_c_binding
real, allocatable :: a(:)
integer(C_SIZE_T) address

allocate (a(10))
address = transfer (c_loc(a), address)
print *, address
end

This at least uses all standard syntax.

Steve

On 2007-08-20 13:41:42 -0300, pelotudo@gmx.de said:

> Hi,
>
> is there any Fortran 2003 standard conforming way of acquiring  the
> address of pointer allocated objects, other than the well-known %loc()
> of loc() extensions?
>
> I have a fortran code implementing a red-black-tree-structure which
> (until now) uses this extension in order to compare addresses. But my
> compiler complains about the F2003 extension. And I am a little bit
> pedantic about it...

If you want to know if two pointers point at the same thing then
there is an intrinsic called ASSOCIATED. It has two forms. With
one argument it finds "null" or not (read the actual fine print).
With two arguments it deternines if they point at the same thing
(there is much fine print over zero sized arrays as per a recent
lengthy thread). All this assumes that you do not literally want
to do what you said but what you meant to have said and we have
to guess a bit about that.

> I know about the c_loc() function from the intrinsic module
> iso_c_binding, but this seems to work only with the interoperable typs
> (c_int, c_double, ...) from the module and not with self-made
> datatypes like this:
>
>   type :: rb_node
>      integer :: color
>      type(rb_node),pointer :: left,right,parent
>      real(dp) :: value
>   end type rb_node
>
> Any ideas?
>
> Cheers,
> thorium90

On Mon, 20 Aug 2007 09:41:42 -0700, pelotudo@gmx.de wrote
(in article <1187628102.336668.221520@57g2000hsv.googlegroups.com> ):

> is there any Fortran 2003 standard conforming way of acquiring  the
> address of pointer allocated objects, other than the well-known %loc()
> of loc() extensions?

Not other than C_LOC, which has restrictions, as you note. It isn't entirely
restricted to interoperable types. I seem to recall that you can do a few
other things. See its doc for details.

Anyway, if you managed to get the addresses, there wouldn't be much useful
you could do with them. Other than passing addresses to C, the things you
could do with addresses fall in the category of being either nonstandard or
already provided by standard features.

> I have a fortran code implementing a red-black-tree-structure which
> (until now) uses this extension in order to compare addresses. But my
> compiler complains about the F2003 extension. And I am a little bit
> pedantic about it...

If you are really pedantic, then you won't use the nonstandard concept of
comparing addresses, no matter how you manage to get them. While that will
usually work in practice, the standard is (intentionally) silent on the
matter. The compiler is theoretically allowed to do some pretty "strange"
things, as long as it gets all the bookkeeping right in the end. (For
example, it  could keep a temporary copy at a different address, with enough
"glue" to make things work; this could conceivably even make sense in some
multi-processor scenarios).

As Gordon mentioned, it sounds like you are just trying to write your own
version of the two-argument form of the associated intrinsic. I'd suggest
just using associated. The zero-sized cases where associated is "tricky" are
also cases where the concept of comparing addresses won't generally work
either.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain


 ________________________________________
________

Hogwasher, Premier News and Mail for OS X
http://www.asar.com/cgi-bin/product.../hogwasher.html
 ________________________________________
________

> use iso_c_binding
> real, allocatable :: a(:)
> integer(C_SIZE_T) address
>
> allocate (a(10))
> address = transfer (c_loc(a), address)
> print *, address
> end
>
> This at least uses all standard syntax.

Yep, but still, from my understanding of F2003, it is not guaranteed to
do what you expect. For one thing, size_t might not be large enough to
store a pointer (or too large, but that's less likely).

--
FX

On Aug 21, 7:02 am, "FX" <coud...@alussinan.org> wrote:

> Yep, but still, from my understanding of F2003, it is not guaranteed to
> do what you expect. For one thing, size_t might not be large enough to
> store a pointer (or too large, but that's less likely).

Perhaps I'm not familiar enough with C to recognize when that might be
the case.  Maybe C_INTPTR_T would be a better choice?

I do agree with others that ASSOCIATED seems better suited to the
purpose stated in the original post.

Steve

> Perhaps I'm not familiar enough with C to recognize when that might be
> the case.  Maybe C_INTPTR_T would be a better choice?

Yep, intptr_t is designed for that purpose. The code you suggest (with
C_INTPTR_T instead of C_SIZE_T) probably isn't guaranteed to work, but it
most probably would work on all compilers.

--
FX