 |
Newsgroups: comp.lang.fortran
From: "James Giles" <jamesgi...@worldnet.att.net>
Date: Mon, 09 Apr 2007 18:20:05 GMT
Local: Mon, Apr 9 2007 2:20 pm
Subject: Re: Transfer and variables that don't use all their storage space.
Richard Maine wrote: ... > I need to use a temp variable to get the effect. First, I claim that What's "not captured in its value" mean? TRANSFER operates > introducing an intermediate variable cannot change the standard's > claim that transfer((transfer(e,d),e) must return E. If that made a > difference, then that would mean that the result of transfer was > somehow not captured in its value. [... on representations, not values. > ...] In particular, if we change it to Assignments operate on values, not internal representations. > d = transfer(e,d) Unless the rules of assignment are *required* to preserve the internal representation, there's no reason to expect this to work. For many types, like INTEGER for example, there's no reason that assignment wouldn't preserve internal representation as well as value (there's usually only one representation of any particular value). But, the standard doesn't *require* the internal representation to be preserved. The description of TRANSFER doesn't claim that an intermediate assignment would preserve the identity in question. It doesn't mention assignments at all. ... > This is for a case where D is of a "benign" type where the assignment Let's rephrase this. Suppose P and Q are pointers to the type of > operator doesn't do anything "odd". > So do > d = transfer(e,d) > where ee is another vairiable of the same type as e. I probably don't > subroutine sub(ee,e) E. And suppose somewhere in the program you wrote: P => E And suppose elsewhere you write: Q => P and the elsewhere you write call sub(Q, E) If SUB doesn't define, redefine, or cause to become undefined either > [...] In particular, the actual arguments Now you've *got* to be kidding! Under your hypothesis (that the > aren't associated in any way acknowledged by the standard, so the > prohibitions against changing the values of the dummies don't apply. intervening assignment doesn't change internal representations) they both refer to the same underlying entities. The rule about aliasing don't say anything about the entities being associated in *acknowledged* ways! If you change the entity, you can only reference the entity through that one dummy argument. That's regardless of how the entities are associated. The word "associated" isn't even used! >> For Well, given the shallow analysis so far in this thread, it's certainly >> all we know, someone in the F90 committee carefully thought >> through all possible cases and found no "havoc" arising from >> any of them. > You have *GOT* to be kidding. :-) Yes, I saw that you labelled it as *very* plausible that F8x people pursued it much further that we have. There were lots more of them and they tended to be more zealously suspicious than the current committee seems to be. > I've seentoo much of the committee close up; I don't think they would I still don't see any problem. You have done enough hand wringing > have thought through all the cases of that one, particularly as... >> That's speculation too (unless someone remembers > "All these years" isn't very many for allocatable components, which that there *might* be a problem. But no *new* problem has been evident (only ones due to other violations of the standard not related to the use of TRANSFER). Your example still does nothing different than CALL SUB(E, E) would do in the same circumstances. Your attempt to characterize it as an unacknowledged form of association doesn't change anything. -- "I conclude that there are two ways of constructing a software 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.
| |||||||||||||