Red-Black-Trees and Fortran 2003 Features 
Author Message
 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



Sat, 06 Feb 2010 00:41:42 GMT  
 Red-Black-Trees and Fortran 2003 Features

Quote:
> 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



Sat, 06 Feb 2010 01:10:19 GMT  
 Red-Black-Trees and Fortran 2003 Features

Quote:
> 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.
Quote:
> 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



Sat, 06 Feb 2010 01:47:24 GMT  
 Red-Black-Trees and Fortran 2003 Features


Quote:
> 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.

Quote:
> 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.pl?58/hogwasher.html
________________________________________________



Sat, 06 Feb 2010 02:26:51 GMT  
 Red-Black-Trees and Fortran 2003 Features

Quote:
> 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



Sat, 06 Feb 2010 19:02:00 GMT  
 Red-Black-Trees and Fortran 2003 Features

Quote:
> 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



Sat, 06 Feb 2010 21:07:36 GMT  
 Red-Black-Trees and Fortran 2003 Features

Quote:
> 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



Sat, 06 Feb 2010 21:11:21 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. red-black trees in fortran

2. searching trees (AVL, 2-3-4 and red-black trees)

3. Red Black Tree - delete function

4. Program to create Red-Black Trees

5. AVL and red-black trees

6. need code for red-black binary search tree

7. Red-Black tree in PROLOG

8. Red Black Tree in PROLOG

9. Red - black trees

10. Red-Black trees

11. Fortran 2003 new features

12. New features of Fortran 2003

 

 
Powered by phpBB® Forum Software