Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.fortran
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Recasting Fortran pointers
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Jugoslav Dujic  
View profile  
 More options Nov 14 2001, 3:50 pm
Newsgroups: comp.lang.fortran
From: "Jugoslav Dujic" <jdu...@yahoo.com>
Date: Wed, 14 Nov 2001 21:55:11 +0100
Local: Wed, Nov 14 2001 3:55 pm
Subject: Re: Recasting Fortran pointers
Print | View thread | Show original | Report this message | Find messages by this author
"Adrian Ferramosca" <adr...@bjahouston.com> wrote in message

news:l0yI7.2662$Oh1.31441@insync...
|
| "Richard Maine" <nos...@see.signature> wrote in message
news:uen11puxyq.fsf@altair.dfrc.nasa.gov...
| > So for each type, I
| > made an array of pointers (using the "usual" trick again; I'm
| > assuming you've followed this group enough to understand it).
|
| not sure what the "usual" trick is  :(
|
| > Where you have "type(xxx), pointer" above, I just substituted a
| > a scalar integer.  That scalar integer is an index into the
| > array of pointers for the appropriate type.  Not very "modern",
| > but it works fine, is reasonably easy to follow, etc.  It helped
| > a lot that I was sure to have a relatively small number of
| > targets, so I could get by with making the arrays of pointers
| > statically sized.  It also helped that targets were added and
| > deleted with relatively low frequency, so that the performance
| > issue of finding an "open" slot for a new one by searching
| > the array was not a problem.
| >
| > I could probbaly drag out some sample code to illustrate if the
| > above words aren't enough, but probably not today.  Other commitments
| > are about to call.
|
| Great, whenever you have a spare moment...
|
| Adrian

Since I happen to know that you use CVF, you might as well stick
to Cray pointers, which are broadly supported in CVF as an extension.
(it even supports Cray pointers to functions). Unfortunately,
it seems that it's not easy to isolate code using crays in a
separate subroutine(s) which "improves" portability.

They're especially useful for lpUserData stuffs which can
be frequently found in Windoze API:

TYPE(MyWindowProperties):: tMWP
!Associate address of tMWP with the window
i = SetWindowLong(hMyWnd, GWL_USERDATA, LOC(tMWP))

!... somewhere else, miles away, in the code:
TYPE(MyWindowProperties):: tMWP; POINTER(pMWP,tMWP)
!..et voila, all associated data are restored:
pMWP = GetWindowLong(hMyWnd, GWL_USERDATA)

Now, it may look like I'm advocating them -- I dislike the
syntax and they can be really dangerous in kids' hands --
but the truth is that I can't live without them in Win32 API
stuff which is C-based and frequently the address
you get may point to quite a various stuff.

Jugoslav
________________________
www.geocities.com/jdujic


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google