Russell, Richard wrote:
> I would have a big problem with use of CHAR and ICHAR. I assume that the intent is to avoid the issue of having to use (nonstandard, but implemented anyway) EQUIVALENCE to locate a character string on top of a real vector that is passed to the generic data manager. I could use a function to convert each character of a string to a string of 1-byte integers via ICHAR, provided the character is within the range 0-127 in the collating sequence (probably so, for my needs). If I needed characters outside that range, then I would need a 2-byte integer for each character. There still would be the pair of DO loops to pack and unpack each string, and the result would start to look ugly. I can't bury this effort inside the data manager, because it does not know the nature of what the caller is having stored or retrieved, only the vector and a count of "words" in it. While I'd rather avoid use of nonstandard (but de facto standard?) code, it has seemed more expeditious and easily unde
rstood to use something like this:
> REAL VECTOR(100)
> CHARACTER*8 STRING1
> CHARACTER*20 STRING2
> ...
> EQUIVALENCE (STRING1,VECTOR(1)), (STRING2,VECTOR(49))
>
This thread has already mentioned TRANSFER as an option to achieve
standard compliance. To be specific in respect of the above example the
following snippet demonstrates the use. You will immediately see the
disadvantages are (i) "movement" of data (as suspected by Richard in an
earlier message) and (ii) as a result it is necessary to repack the data
at the end of the routine in the event that the strings are altered.
REAL VECTOR(100)
CHARACTER*8 STRING1
CHARACTER*20 STRING2
...
!!! EQUIVALENCE (STRING1,VECTOR(1)), (STRING2,VECTOR(49))
! ... Unpack ...
STRING1 = TRANSFER(VECTOR(1:LEN(STRING1)), STRING1)
STRING2 = TRANSFER(VECTOR(49:LEN(STRING2)+48), STRING2)
.... Modify STRING1 & STRING2 ??
! .... Repack ...
VECTOR(1:LEN(STRING1)) = TRANSFER(STRING1,0.0,LEN(STRING1))
VECTOR(49:LEN(STRING2)+48) = TRANSFER(STRING2,0.0,LEN(STRING2))
> This example would let the caller have a collection of data 100 words long, with words 1-2 being used for the short string and words 49-53 for the long string. The collection could be passed to/from the data manager with a single call. If the default real is longer than 4 bytes, the code still would work, with some waste of space. Should each character occupy 16 bits, then the default real size would indeed have to be doubled.
>
> Sooner or later, the possibility of using derived types to create structures of data comprised of different types will be suggested. That would create a problem of passing data to/from the data manager, which isn't suppposed to know anything about the structure of the data being moved. I suspect also that storage arrangement of elements of a structure is not defined by the standard, beyond what the SEQUENCE statement does, but frankly I don't know.
>
> RAR
>
> -----Original Message-----
> From: Fortran 90 List [mailto:[log in to unmask]]On Behalf
> Of Robin
> Sent: Thursday, March 11, 2004 5:20 AM
> To: [log in to unmask]
> Subject: Re: Data type "UNDEFINED"
>
>
>
>>Date: Wed, 10 Mar 2004 08:22:59 -0500
>>From: "Russell, Richard" <[log in to unmask]>
>>
>
>>No, I didn't try TRANSFER. I actually had to look it up to see what it does,
>>and it still isn't totally clear to me.
>>It seems to be a "move" of sorts, and is something that was added in Fortran 95.
>>
>>Perhaps someone familiar with the equivalence issue can explain why
>>equivalence of character and non-character entities is not allowed in the standard,
>>
> ? particularly since doing so can be implemented
>
>
> Maybe CHAR and ICHAR are better?
>
>
>>RAR
>>
>
> -----------------------------------------
> *****************Internet Email Confidentiality Footer******************
>
> Privileged/Confidential Information may be contained in this message.
> If you are not the addressee indicated in this message (or responsible
> for delivery of the message to such person), you may not copy or deliver
> this message to anyone. In such case, you should destroy this message
> and notify the sender by reply email. Please advise immediately if you
> or your employer do not consent to Internet email for messages of this
> kind. Opinions, conclusions and other information in this message that
> do not relate to the official business of The Shaw Group Inc. or its
> subsidiaries shall be understood as neither given nor endorsed by it.
> ________________________________________________________________________
> The Shaw Group Inc.
> http://www.shawgrp.com
>
--
David Vowles,
School of Electrical and Electronic Engineering,
The University of Adelaide,
Australia, 5005.
|
