Alvaro Fernandez wrote:
> I think I agree with you - there is no reason why the equivalence trick
> should be purposely disallowed. It sounds to me like some of the excesses of
> structured programming, which sometimes placed unreasonable restrictions on
> programming practice, with dubious benefits and obvious drawbacks.
The reasons for the restriction has nothing to do with "structured
programming", or any sort of style issue. It is simply because X3J3
did not want to fix the relationship between the amount of storage
occupied by a character and that of a real or integer. (Doing that
with logicals many years ago forces each default logical to be stored
in way more space than is needed.)
(E.g. you
> weren't supposed to jump out of a loop even using something like EXIT, but
> where forced to set a flag and check for that flag in the conditional part
> of the loop, complicating error checking.)
I certainly don't agree with this advice and those who put the EXIT into
Fortran 90 apparently didn't either. Following this would be carrying
somebody's idea of "structured programming" into the realm of the silly.
> As for TRANSFER(),what it does is take an argument of one kind of variable
> (say real) and then it transfers the bits into another variable, say
> integer. You provide the "mold" for what you want the result to fit into. It
> should do what you want, _but_ I have heard that it is not implemented very
> well in most compilers. I wrote a module to do this kind of transferring
> between types once - maybe I can dig it up. Never profiled it, so I don't
> know how bad it may be. And if your code isn't broken, then why fix it? :-)
>
>
> Alvaro Fernandez
>
>
> -----Original Message-----
> From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
> Russell, Richard
> Sent: Wednesday, March 10, 2004 7:23 AM
> To: [log in to unmask]
> Subject: Re: Data type "UNDEFINED"
>
> 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. I am not sure what I would do
> with it. I think the issue is more in the routines that call the data
> manager; that routine just gets an argument vector that is ostensibly
> "real," and does only copying to move things around, not really caring about
> the type of data "in the box," as you put it. The code for this was written
> back in the mid 80s to the Fortran 77 standard, and I haven't had any need
> to upgrade it. I don't plan to upgrade it until forced to do so or at least
> a "good" portable solution is at hand.
>
> 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 by a compiler;
> Lahey has allowed this override since F77L. I suppose it can be an issue if
> a machine architecture is such that an integer or real word size is not an
> even multiple of character size. But character strings have to be put
> somewhere, in the same kind of real memory as numeric data occupy, and they
> have locations. So why shouldn't the starting point of a string be
> controllable? Boundary alignment issues?
>
> RAR
>
> -----Original Message-----
> From: Fortran 90 List [mailto:[log in to unmask]]On Behalf
> Of Alvaro Fernandez
> Sent: Tuesday, March 09, 2004 5:23 PM
> To: [log in to unmask]
> Subject: Re: Data type "UNDEFINED"
>
>
> I'm curious: Did you try TRANSFER(), or was it too slow?
>
> -----------------------------------------
> *****************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
>
>
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road [log in to unmask]
Tucson, AZ 85750 USA http://www.fortran.com
|
