problem in interface
in [Fortran]
|
Prev: What exactly does the SAVE statement do ?
Next: "static" explanation. What exactly does it mean?
From: rudra on 25 May 2010 14:35 On May 25, 11:03 pm, dpb <n...(a)non.net> wrote: > > its not possible to include the lm_a in a module > > Why not? this is because, this lm_a is from an old code, used as a library >You didn't give the variable declarations in the subroutine itself, Actually, I prefer module over interface, and this is the first time I am using interface in long time. So, what in my mind is if they are declered correctly. I have some confusion, may be a RTFM, but plz reply. 1)inside interface, arguments of the subroutine is as declared in the main code or as declared in the subroutine source itself?
From: dpb on 25 May 2010 14:45 rudra wrote: > On May 25, 11:03 pm, dpb <n...(a)non.net> wrote: > >>> its not possible to include the lm_a in a module >> Why not? > this is because, this lm_a is from an old code, used as a library Meaning you don't have source? If you have source still don't see why it can't become a module. If you don't then you have compiled version that is compatible w/ current other compilers? >> You didn't give the variable declarations in the subroutine itself, > Actually, I prefer module over interface, and this is the first time I > am using interface in long time. So, what in my mind is if they are > declered correctly. I don't yet see why you have any need for an explicit interface, but... > I have some confusion, may be a RTFM, but plz reply. > 1)inside interface, arguments of the subroutine is as declared in the > main code or as declared in the subroutine source itself? All have to be consistent; that's the problem w/ manually writing interface blocks; it's your task to ensure each of those independent as far as the compiler is concerned definitions are identical. Normally there are two places; the calling routine and the subroutine body. You've now added a third, the interface body. The compiler sans modules sees all of these as independent compilation units and can't do anything to help given that you've deliberately chosen to tie its hands by not using modules. --
From: Richard Maine on 25 May 2010 15:02 rudra <bnrj.rudra(a)gmail.com> wrote: > This might be a silly question and/or i am missing a faq Yes, you are missing a faq. > I have a subroutine declared as: [big mess elided] > In the main program, I have defined an interface [more mess] > but as soon as it getes asnit, it gives segmentation fault, .... > plz help Off-hand, I'd guess that something is wrong with the subroutine call. :-) I suppose it might be something wrong somewhere else and showing symptoms here. As to what it is, who knows? I can't manage to follow all of what you did show; it is too big a mess. Odds are that even if I went through and carefully checked item by item, I still would not find it because you didn't show everything. The FAQ that you missed is to show the relevant declarations - *ALL* of them. That is a *VERY* frequent issue; in fact, I'm quite sure it has come up with you before. No, you have not shown all the relevant declarations. With a separate interface body like you have, the relevant declarations would include at least the declaration of every single argument in all 3 places. Yes, I said 3. The dummy arguments in the subroutine and the interface body, and the actual arguments in the calling procedure. If any of the arguments don't have declarations in any of those places, then you have missed another FAQ - to use implicit none to force declarations of everything. In the extreme case, we might have to see the entire subroutine and the entire caling subroutine because even if we see a declaration for each argument, that doesn't necessarily mean that there isn't an additional declaration elsewhere that adds an important attribute. That's probably going farther than most likely needed, but you are way too far on the other side. Alas, even of you do include all the declarations, it is going to be too big a mess to manually check. I don't put that kind of work into my own codes; don't see why I should for others. As dpb notes, that kind of a mess of an argument list is an almost sure sign of... umm... how to put it at least a little gently... a need for improvement in code design and organization. That you are having trouble with it is no surprise; pretty much any human would have trouble with such a mess. We aren't equipped to grasp that many things all at once. To have a chance of being done right, non-trivial codes need to be written so that humans can understand them. It isn't enough for the compiler to do so. If you really can't reorganize the code better, the next best thing is to at least put the procedure in a module. That way, you only have 2 places to study instead of 3 (as you no longer have an interface body). And the compiler will catch a lot of cases of mismatch netween those two. Computers do that kind of thing a lot beter than humans. By putting it in a module, you give more of teh work to the computer, putting less burden on us poor humans. You said in response to dpb that it is "not possible" to include the subroutine in a module. There are very few reasons why that can be "not possible". Most of them are pretty esoteric and I seriously doubt you could even name them. (I'd have trouble myself; I could not do it off the top of my head.) If the code actually has one of those esoteric things that I can't even recall, maybe that's its problem. But since you give no hint as to why it is "not possible", that doesn't help much. All I can say otherwise is to go through each and every argument. Donly skip one, no matter how trivial it might seem. Check its declaration in each of the 3 places. Don't guess what you recall it as being or ought to be. Actually find and look at the declaration. If you can't find one, see above about implicit none. If it is too much trouble for you to use implicit none, then it is certainly *WAY* too much trouble for me to deal with the consequences for you. Yes, checking all of them is going to take a lot of time, I know. If "not possible" really means that you don't want to bother, then I guess my reply has to be that it is not possible for me to debug the problem based on what you presented. In my case, the "not possible" is a bit more literal in that the needed information most likely is not there, and if it is there, the mess is beyond my ability to grasp. I suppose I could have done the most trivial test and counted the arguments, but even that seems like too much pain. Taking my shoes off would not be enough. I'd probably have to take my wife's shoes off as well.... hmmm. :-) -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: mecej4 on 25 May 2010 15:34 rudra wrote: >> > its not possible to include the lm_a in a module >> >> Why not? > this is because, this lm_a is from an old code, used as a library > You seem to imply that in order to write a module you need the source code for the routines. Not so. A module may contain just interface definitions with not a single executable statement in it. For example: MODULE BESSEL_I INTERFACE FUNCTION J0(X) REAL :: X, J0 END FUNCTION J0 END INTERFACE END MODULE BESSEL_I > Actually, I prefer module over interface, and this is the first time I > am using interface in long time. So, what in my mind is if they are > declered correctly. > I have some confusion, may be a RTFM, but plz reply. > 1)inside interface, arguments of the subroutine is as declared in the > main code or as declared in the subroutine source itself? The latter, if by "as declared in the main code" you really mean "as invoked in the caller". A subroutine CALL statement is not a declaration. -- mecej4
From: Richard Maine on 25 May 2010 15:35
dpb <none(a)non.net> wrote: > rudra wrote: > > On May 25, 11:03 pm, dpb <n...(a)non.net> wrote: > > > >>> its not possible to include the lm_a in a module > >> Why not? > > this is because, this lm_a is from an old code, used as a library > > Meaning you don't have source? If you have source still don't see why > it can't become a module. If you don't then you have compiled version > that is compatible w/ current other compilers? Wow. I figured the problem was likely to be in something that wasn't shown, but I didn't even think about that possibility. Seems like a very real one, though. Don't skip over that last sentence quoted above too quickly. That could be a real problem (and the symptoms aren't far off from what one might expect). I'd suggest recompiling the library with the *SAME* compiler as you are using for the rest of the code. Note that "same" is much better than "alleged to be compatible". "Same" also means the same version as opposed to some previous version from the same vendor. Oh, and with the same swich settings (I'm thinking of things like 32-bit vs 64-bit switches, but there are some others as well). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |