Coding guidelines question
in [Fortran]
|
From: James Giles on 15 Mar 2006 22:06 John Harper wrote: > In article > <Gr3Sf.567858$qk4.49132(a)bgtnsc05-news.ops.worldnet.att.net>, James > Giles <jamesgiles(a)worldnet.att.net> wrote: >> >> Defined operators I also support >> but with even stronger misgivings. I don't think anything >> would convince me that allowing users to define the precedence >> of their defined operators was a good idea. > > Having had that in Algol 68, and wanting to do 3-D vector analysis > in Fortran in which .DOT. and .CROSS. would have to be defined ops > with the same precedence as * (the usual maths convention), I > disagree. As much as it wouldbe convenient to have that, if I'm using your code, how do I know you've done it? If precedence is definable, there is nothing about the appearance of the operator to tell me what precedence it has. At present, in Fortran, I *can* tell exactly what precedence all operators have just by inspection of the operators - I never have to look at any declarations. Never mind that definable precedence is *much* harder to implement, it's also much harder to document and read for us ordinary humans. Now, I've suggested this before, but what about allowing users to define meanings for presently unassigned operator symbols that have predefined precedences? There aren't many if we stick to ASCII, but there are some. The two character operator */ has no meaning in Fortran, could be given the same precendence as *, and could be defined with the meaning "cross product". Similarly, /* could be given a meaning. Etc. Now, instead of these combinations, I'd prefer to allow latin-1 characters. That has such symbols as centered dot (?), cross product (?), conventional divide (?), and a few others whose precedence could be defined by the language and whose meaning could be defined by the user. -- 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
From: Gordon Sande on 15 Mar 2006 22:06 On 2006-03-15 20:12:53 -0400, "James Giles" <jamesgiles(a)worldnet.att.net> said: > Walt Brainerd wrote: >> James Giles wrote: > ... >>> You are using *all* those operators and assignments >>> in each local context? You must have some very busy >>> code. >>> >> The particular example is using a module that defines >> a big integer data type. >> >> I have a hard time imagining many lines of code that >> do integer arithmetic that don't use add, subtract, >> multiply, divide, sqrt, assignment, compare (there's >> six right there) operations, but maybe your imagination >> is better than mine. > > Well, I guess so. Most uses of big-integers are for an > expression or two, maybe a few lines even, to accomplish > things beyond the ability of the intrinsic INTEGER (or > even REAL) type(s). This small amount of code may > actually use only, say, add, divide, and assignment (to > compute the average of a large array of integers without > the risk of overflow, and without losing precision like > you would if you use REAL intermediates). I have seen a couple serious applications of rather long integers. In each case the operations were quite serious mathematics and involved nontrivial programs. There are several packages of nontrivial operations research or combinatorics that are exact as they use a high precision integer package. My experience must be limited as I have never seen a case where the intent was to have a bit more precision for a while. I have seen some things that are sort of like that for reals but never for integers.
From: Dave Thompson on 19 Mar 2006 21:35
On Wed, 08 Mar 2006 15:37:28 GMT, Dan Nagle <dannagle(a)verizon.net> wrote: > Hello, > > Pierre Asselin wrote: > > <snip a bunch> > > > Playing Devil's Advocate, in C the tradition is to #include all headers > > at file scope and to #include needed headers from headers. Transliterated And specifically to #include all headers _at the top_ of the source file -- certainly before any code, and usually before any (file-scope) variables or types. The second is not universal however. I have seen projects where you must (and it is documented you must) #include "lowerlevel.h" before you #include "mediumlevel_uses_lower.h". (The actual names aren't that explanatory, of course. <G>) Although I would say in recent years the trend is toward "medium.h takes care of it for you". > > to Fortran, that would mean USE at module scope (contrary to what I said) > > and single-module wrappers (as I said). > > Playing Devil's Advocate further, an unqualified private statement > in each module to prevent "leak-through" of names could be considered > the equivalent of the ubiquitous C construct > > #ifndef FUBAR_H > #define FUBAR_H > > /* stuff from fubar.h */ > > #endif No. This (only) protects against (arguably spurious) errors caused by nominal duplication(s) if you #include the same header twice -- which you don't normally do explicitly, but as above get if you #include "lower.h" and also #include "medium.h" which includes lower.h. Everything declared in fubar.h is still visible and in the namespace. You may thinking of things like /*--- unistd.h or similar ---*/ .... here features in the "basic" API ... #ifdef _XPG_SOURCE_LEVEL_2 .... here features applicable only to level 2 ... #endif etc. or things like /*--- myproj.h ---*/ extern myfunc (blah blah blah) ; extern struct { int a; float b; char * c; } mydata #ifdef IMPLEMENTATION_PRIVATE = { 42, 3.1416, "whoa nelly" } #endif ; - David.Thompson1 at worldnet.att.net |