Fortran Programming Language :: Bundling multiple objects into a single module?


	Bundling multiple objects into a single module? Hi, I have a number of fairly complicated objects. Each object is contained in its own module, but they are very similar. All the methods are the same, and the code is identical except for type declarations. I have two questions concerning this: First, is there a way to reuse the code? It was easy enough to duplicate and do global search and replace to get what I wanted, but documenting everything is still going to cost multiple trees. Second, is there a way now to bundle the objects together in a single module, so that instead of use object001 use object002 ... use objectnnn I can simply say use objects Thanks for any ideas. gus gassmann Gus Gassmann wrote: > Hi, Hi. > Each object is contained in its own module, but they are very similar. > All the methods are the same, and the code is identical except for type > declarations. Blatant DRY[1] violation. > I have two questions concerning this: First, is there a > way to reuse the code? We rolled our own templating system in Ruby, which we haven't managed to release yet, but at least three alternatives exist: http://www.macanics.net/forpedo/ http://users.erols.com/dnagle/coco.html INCLUDE statements Regards, -- Bil Kleb http://funit.rubyforge.org [1] http://en.wikipedia.org/wiki/Don't_repeat_yourself "Gus Gassmann" <Horand.Gassm@dal.ca> wrote in message news:1178111009.733808.151530@y80g2000hsf.googlegroups.com... > I have a number of fairly complicated objects. Each object is > contained in its own module, but they are very similar. All the > methods are the same, and the code is identical except for type > declarations. I have two questions concerning this: First, is there a > way to reuse the code? Others will reply about how to peform some form of generic programming in f95, but suffice it to point out that if the code is really common you can keep it in one place and insert it by means of an INCLUDE line wherever it's needed. > Second, is there a way now to > bundle the objects together in a single module, so that instead of > use object001 > use object002 > ... > use objectnnn > I can simply say > use objects Put all the USEs into a module called objects and use objects, just as you've written. Regards, Mike Metcalf On May 2, 10:27 am, "Michael Metcalf" <michaelmetc@compuserve.com> wrote: - Hide quoted text - > "Gus Gassmann" <Horand.Gassm@dal.ca> wrote in message > news:1178111009.733808.151530@y80g2000hsf.googlegroups.com... > > I have a number of fairly complicated objects. Each object is > > contained in its own module, but they are very similar. All the > > methods are the same, and the code is identical except for type > > declarations. I have two questions concerning this: First, is there a > > way to reuse the code? > Others will reply about how to peform some form of generic programming in > f95, but suffice it to point out that if the code is really common you can > keep it in one place and insert it by means of an INCLUDE line wherever it's > needed. > > Second, is there a way now to > > bundle the objects together in a single module, so that instead of > > use object001 > > use object002 > > ... > > use objectnnn > > I can simply say > > use objects > Put all the USEs into a module called objects and use objects, just as > you've written. > Regards, > Mike Metcalf I tried that first, but the linker gave me a raft of "unresolved external symbol" errors. I attributed this to the compiler realizing that the wrapper module objects does nothing and optimizing everything away. It looks like I am barking up the wrong tree, but I don't know where else to start. "Gus Gassmann" <Horand.Gassm@dal.ca> wrote in message news:1178112940.254977.133050@o5g2000hsb.googlegroups.com... > I tried that first, but the linker gave me a raft of "unresolved > external symbol" errors. I attributed this to the compiler realizing > that the wrapper module objects does nothing and optimizing everything > away. It looks like I am barking up the wrong tree, but I don't know > where else to start. IIRC, in cases where a module contains no procedures, you need to reference name.mod or some such at the link step. Regards, Mike Metcalf > I tried that first, but the linker gave me a raft of "unresolved > external symbol" errors. I attributed this to the compiler realizing > that the wrapper module objects does nothing and optimizing everything > away. It looks like I am barking up the wrong tree, but I don't know > where else to start. That would mean a bug in the compiler. But I guess that it's most likely you who's making a mistake. If you show the relevant code and how do you compile, someone can tell you what is wrong. Gus Gassmann <Horand.Gassm@dal.ca> wrote: > On May 2, 10:27 am, "Michael Metcalf" <michaelmetc@compuserve.com> > wrote: > > Put all the USEs into a module called objects and use objects, just as > > you've written. > I tried that first, but the linker gave me a raft of "unresolved > external symbol" errors. I attributed this to the compiler realizing > that the wrapper module objects does nothing and optimizing everything > away. That seems very unlikely. This is also a perfect example of principle number one of asking for debugging help: Show us the facts rather than your interpretation of the facts. Your interpretation has high odds of being wrong - after all, there is something you don't understand or youwouldn't be asking for the help. So if an incorrect interpretation is all we have to go by, the odds of us being able to help much are low. (The "you" here is a generic one rather than a personal one; this principle is illustrated here a LOT, not just by you personally). I'd suggest showing the actual code, along with the exact commands used to compile all steps. Since compilation and linking issues are compiler-specific, also mention the particular compiler and operating system. I'd guess that the problem is something trivial. I can imagine these symptoms comming from trivial errors either in coding and in compilation/linking. But I don't have enough data to speculate usefully. -- Richard Maine \| Good judgement comes from experience; email: last name at domain . net \| experience comes from bad judgement. domain: summertriangle \| -- Mark Twain - Hide quoted text - Gus Gassmann wrote: > Hi, > I have a number of fairly complicated objects. Each object is > contained in its own module, but they are very similar. All the > methods are the same, and the code is identical except for type > declarations. I have two questions concerning this: First, is there a > way to reuse the code? It was easy enough to duplicate and do global > search and replace to get what I wanted, but documenting everything is > still going to cost multiple trees. Second, is there a way now to > bundle the objects together in a single module, so that instead of > use object001 > use object002 > ... > use objectnnn > I can simply say > use objects > Thanks for any ideas. > gus gassmann One way is to take the common code and place it in a file that is included in all of the subroutines. Then you only need to generate the headers and footers for each routine. Something like subroutine x_real(x) real x include "the_common_code" end subroutine x_real subroutine x_int(x) integer x include "the_common_code" end subroutine x_int Somewhat tedious, but at least straight forward. Dick Hendrickson On May 2, 12:14 pm, Dick Hendrickson <dick.hendrick@att.net> wrote: - Hide quoted text - > Gus Gassmann wrote: > > Hi, > > I have a number of fairly complicated objects. Each object is > > contained in its own module, but they are very similar. All the > > methods are the same, and the code is identical except for type > > declarations. I have two questions concerning this: First, is there a > > way to reuse the code? It was easy enough to duplicate and do global > > search and replace to get what I wanted, but documenting everything is > > still going to cost multiple trees. Second, is there a way now to > > bundle the objects together in a single module, so that instead of > > use object001 > > use object002 > > ... > > use objectnnn > > I can simply say > > use objects > > Thanks for any ideas. > > gus gassmann > One way is to take the common code and place it in a file that > is included in all of the subroutines. Then you only need to generate > the headers and footers for each routine. Something like > subroutine x_real(x) > real x > include "the_common_code" > end subroutine x_real > subroutine x_int(x) > integer x > include "the_common_code" > end subroutine x_int > Somewhat tedious, but at least straight forward. > Dick Hendrickson- Hide quoted text - > The drawback is, of course, that I then have many, many files, one for each method. It's interesting that nobody suggested a literate programming system such as FWEB---not that I would actually want to venture there, anyway... (I know that FWEB supports f77 only, but is there no demand for an F95WEB?) Have Don Knuth's ideas been rendered obsolete? What is the consensus here? Gus Gassmann wrote: > It's interesting that nobody suggested a literate programming system > such as FWEB---not that I would actually want to venture there, > anyway... (I know that FWEB supports f77 only, but is there no demand > for an F95WEB?) Have Don Knuth's ideas been rendered obsolete? What is > the consensus here? I don't think they're so much "obsolete" as "never caught on in the mainstream". Well, more accurately -- there were two main key ideas in Knuth's original WEB. One of them was typesettable comments, and a general style of using them that really didn't depend that much on computer support. The other was "reordering" code so that it made the most sense to a reader. Modern computer languages offer substantially more flexibility in code-ordering than the ones Knuth was working did, and so to that extent the ideas have become so mainstream as to be invisible. Personally, in the typesettable-comments side of things, my "f95totex" program (I've put it online; a Google-search should find it easier than I can remember url at this hour) does enough of the rest of the literate programming things to keep me happy. It still would be nice to have some of the indexing and cross-referencing features of WEB, though.... (But, again, something like that in an interactive sense has now become a reasonably common feature of programming IDEs.) - Brooks -- The "bmoses-nospam" address is valid; no unmunging needed. Brooks Moses wrote: > It still would be nice to have some of the indexing and > cross-referencing features of WEB, though.... (But, again, something > like that in an interactive sense has now become a reasonably common > feature of programming IDEs.) For indexing and cross-referencing, I like the LXR package. I had to make some minor modifications to it so that it would behave right with Fortran (something to do with casing of names, IIRC), and it doesn't understand fixed form really, but it's quite nice for indexing and cross-referencing free form code. On May 3, 2:36 am, Brooks Moses <bmoses-nos@cits1.stanford.edu> wrote: ... > Well, more accurately -- there were two main key ideas in Knuth's > original WEB. One of them was typesettable comments, and a general > style of using them that really didn't depend that much on computer > support. The other was "reordering" code so that it made the most sense > to a reader. [...] Unfortunately, people less clever than Knuth often reordered the code so that it was substantially less legible. The code was often buried in a novel-like knot of excessive commentary. Since comments are not considered by the compiler they could have been the first chapter of "Gone With the Wind" for all the real consequence they have. You need to clearly see the actual code to be able to read it. How many times in this very newsgroup do you get the remark that posting a description of a problem is not sufficient to get useful answers: you need to post actual code. What's worse is that those same people thought the commentary clarified so well that they didn't need mnemonic identifiers. So even after the code was extracted from the novel it was still difficult to read. It was these abuses of "literate programming" that lead me to believe that code should mostly be self- documenting. That is: if you can assume that the reader has a clear understanding of the algorithm being implemented and a clear understanding of the language being used, the only comments should be occasional clarifications of anything subtle or often misunderstood. These "dangerous turnings" should only need a brief note off to the right which might even refer the reader to some separate document (as below). But, mostly, the code should be comment free. Yes, you still do need the complete description of the algorithm, and maybe of the language or conventions used (like functions with side-effects?). But the appropriate place for that is a separate description (or even a reference to a commonly owned textbook - like some of Knuth's works). -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare Dear Gus, If the methods are the same for various data types, they are most likely dealing only with the contents of the objects. You might want to write a module for each object with only calling codes, and one module with the methods, where all the actual algorithms are stored. Something along the lines of: -------------------------------------------------------- module object001 use methods type object001 real :: x end type interface set_x module procedure obj001_set_x end interface contains subroutine obj001_set_x(obj) type(object001), intent(inout) :: obj call set_value(obj%x) end subroutine end module ---------------------------------------------------------- do the same for object002 ... objectnnn ---------------------------------------------------------- module methods contains subroutine set_value(x) real,intent(inout) :: x x = 1.0 end subroutine set_value end module ----------------------------------------------------------- You still have multiple modules for all the object files and they all have still very similar codes. However, the core of the code (= the methods) is now in one file only, which is convenient for maintenance and extensions. Note that I use an interface in the object modules. In this way you can use set_x in the calling code, regardless the data type of you argument. I hope this helps. Arno