Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

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:

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

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:

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

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc