equivalencing character*8 and double precision
in [Fortran]
|
From: Richard Maine on 21 Jun 2010 17:23 Lynn McGuire <lmc(a)winsim.com> wrote: > double precision VDY .... > character*8 svdy (2) > But as noted, the equivalence between vdy and svdy appears > to be a major extension to only some compilers. Yes. I recall running into compilers that refused that kind of equivalence. > We are slowly removing the last of the Hollerith code out of > our code I suppose it isn't surprsing that removing Hollerith usage was also what I was doing when I ran into that problem. But in my case, that was about 30 years ago. :-) I don't recall the details or what I ended up doing instead. But I sure do recall concluding that I needed to pay attention to that particular bit in the standard if I expected my code to be portable across compilers that I had specific need for my code to work with. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 21 Jun 2010 17:36 Lynn McGuire <lmc(a)winsim.com> wrote: > Is this considered bad code ? Or is this an extremely > common fortran compiler extension ? > double precision vdy (1000000) > character*8 svdy (1000000) > equivalence (vdy, svdy) I note from Fortran 2003, 15.2.3: "There is no Fortran type that is interoperable with a C union type." As far as the Fortran standard, there is no requirement that double precision and character*8 have the same size. It might be slightly better to use REAL*8 instead, though that makes it non-standard in a different way. The C union allows one to do something like this, without the requirement that they be the same size. So, assuming your compiler allows it, it is system dependent that the two have the same size. The program will fail badly if the sizes are different. -- glen
From: dpb on 21 Jun 2010 17:38 Lynn McGuire wrote: >> Back in the good old days, memory was scarce and expensive. >> Now, it's cheap. I'd try getting away from the EQUIVALENCE >> and just declare 6 or so large arrays of the basic types >> you need. dfbk can still work just as it does now. But, >> it will effectively "allocate" ncp double words in each of >> the large arrays, wasting 5/6th of them. But, so what. > > On 2nd thought, this would not work since the value location is > a return value to a heap location from malloc. If svdy, vdy > and ivdy are not the same memory location then one would need > a separate location pointer for each memory type. Which comes back to the issue of why do the different memory types have to overlay each other -- other than that's the way the memory heap was laid out? Is there really a case of the EQUIVALENCE of data types doing something or is it just an overlay of the memory depending on which subroutine is using the global heap at the moment? All I've seen so far indicates the latter. If so, it would seem allocatable and passing the arrays based on that dynamic allocation would be the ticket home. Other than that, the only thing I can see is as noted earlier, you could build a UDT w/ pointers (I think; I decided it wasn't worth fooling with further w/o far more of the picture than have at the moment...) --
From: Lynn McGuire on 21 Jun 2010 17:57 > Which comes back to the issue of why do the different memory types have to overlay each other -- other than that's the way the memory > heap was laid out? So that my code like this will work: call dfbk ('mynewbank', location, 20) vdy (location + 1) = 1.0 ivdy (location + 2).i = 6 ivdy (location + 3).s = 'a name' vdy (location + 4) = spec (4) vdy (location + 5) = spec (9) ivdy (location + 6).l = .false. ivdy (location + 7).l = .true. .... Thanks, Lynn
From: mecej4 on 21 Jun 2010 18:03
On 6/21/2010 12:25 PM, Lynn McGuire wrote: > Is this considered bad code ? Or is this an extremely > common fortran compiler extension ? > > double precision vdy (1000000) > character*8 svdy (1000000) > equivalence (vdy, svdy) > > Thanks, > Lynn Why do you seek to use EQUIVALENCE? If the only answer is conservation of memory, the answer to your problem is: remove the EQUIVALENCE statements! The 8 MB of memory in consideration is a drop in the bucket. Here is an experiment that you can do. Comment out the EQUIVALENCE statements on a working copy of your source code. Compile and run test cases. -- mecej4 |