Re: [AMBER-Developers] Amber coding standards

From: Joe Krahn <krahn.niehs.nih.gov>
Date: Mon, 30 Mar 2009 20:54:19 +0100

Robert Duke wrote:
> This may not be the exact piece of mail to reply to on this thread. But on
> the subject of allocatable storage, it is extraordinarily simple to just put
> all the allocatables that will persist past some subroutine call at the
> module level, and then for all such modules containing allocatable storage,
> include the equivalent of a constructor, say init_foo() for module foo. You
> can then also have the equivalent of a destructor if you need it, and
> everything wrt data allocation is pretty simple and clean. You may find
> that this sort of data has to be stuffed off in modules of relatively
> limited scope due to circular dependency issues that arise in a module-based
> language that generate and use module files at compile time (c headers are
> much easier to structure a piece of s/w around). But I am sort of amazed at
> all the discussion around this stuff. The approach I have used in pmemd is
> pretty simple and straightforward, and available as at least one workable
> example. Had I rather be working in another language? Probably, but this
> stuff is not that hard to do. And on pointers, given that we generally have
> a clue regarding how big things can get, you almost never need them (give me
> an OS problem in c or c++ and I will pointerize the dickens out of it). And
> they are inefficient if you have vectorizable ops. And for most of the
> things we do, index offsets are a more efficient implementation. There are
> undoubtedly problem domains within the code to which these comments don't
> really neatly apply.
> Regards - Bob


The big problem here is that Fortran programmers learn by looking at old
code and trial-and-error, rather than reading languages documentation.
The result is propagation of poor programming habits, and poor
understanding of the language. The overlap between pointers and
allocatables makes it hard to do the right thing based on
trial-and-error. Hopefully, my Wiki summary will help.

Bob's suggestion for module "constructors" and "destructors" is good.
Some well-organized programmers require all modules to have both a
constructor and a destructor, even if they don't really need one. Then,
a script like Amber's "makedepend" will also generate source code that
call all of the constructor and destructor routines, in an order that
honors module dependencies. Or, if you don't want mandatory routines, a
comment at the top of each module file can contain hints for the
makedepend script.

Joe

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:10:22 PDT
Custom Search