Re: Fortran 2003/2008 features and compiler poll
- From: Gary Scott <garylscott@xxxxxxxxxxxxx>
- Date: Wed, 11 Jun 2008 21:25:11 -0500
Richard Maine wrote:
Gary Scott <garylscott@xxxxxxxxxxxxx> wrote:
No, I was aware of the tie to builds and automatic code generation. Seems like a kludge. I don't like the concept of including a CONTAINS
which implies that something is to follow and then not providing something following. It makes for "unclean" (sloppy) source code. It
can't be all that difficult to check for this in any minimally capable
build or autocode generation tool. Seems like laziness to me.
Nah. There are lots of concrete good reasons for having empty contains.
In fact, all this "feature" does is remove a restriction that was
pointless anyway. With the restriction, one had to do pointless
special-case coding for no particular reason.
Picture stub modules where one includes some number of options, possibly
zero. I suppose that one could special-case the zero possibility, but
why on earth insist on such silliness? And that means that you do have
to use a more complicated autocoder instead of a simple include
mechanism.
But it was the type extension stuff that changed this restriction from a
silly one to a completely unacceptable one, and caused it to get
removed.
It is common - very much so - for a type inheritance tree to start with
a base type that has no components. That's particularly so if it is an
abstract type. If you keep the restriction against empty derived types
(which was pretty much all part of the same package of restricting
against empty things), then you end up forced to add a fake component
that does absolutely nothing except be the required component. If you
think that is more "clean" than having an empty type, we might as well
stop the discussion because our notions of cleanliness have not enough
in common to form a basis for discussion.
I suppose you also dislike zero-trip DO loops and zero-sized arrays? I
put them all in the same class of things that have natural and useful
extensions to the zero case. I thought it was great when f77 allowed me
to remove all the special-case code to branch around DO loops when the
trip count was zero. I thought it greatly cleaner (and less error prone)
to have the language just do the "obvious" thing, which also turns out
to be the "right" think in most cases, which was to do the loop zero
times if that's what you asked for. There is an equally obvious
interpretation of contains blocks with nothing contained, or derived
types with no components (particularly if is an abstract type that
always gets extended before use), if blocks with no body, etc...
I suppose you also think that
if (some_condition) then
!-- Nothing here
end if
should be disallowed and people forced to special-case preprocessors to
remove all such IF blocks?
I think the compiler should generate a warning message that you've tested for a condition for which no action is specified. Likewise, for empty contains, that you have told the compiler to expect subsequent code but have not provided any. This is after all include operations have completed.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows it can't be done.
-- Henry Ford
.
- References:
- Fortran 2003/2008 features and compiler poll
- From: Tobias Burnus
- Re: Fortran 2003/2008 features and compiler poll
- From: GaryScott
- Re: Fortran 2003/2008 features and compiler poll
- From: James Van Buskirk
- Re: Fortran 2003/2008 features and compiler poll
- From: Gary Scott
- Re: Fortran 2003/2008 features and compiler poll
- From: Richard Maine
- Fortran 2003/2008 features and compiler poll
- Prev by Date: Re: The linf project (2)
- Next by Date: Re: Sun Studio 12, 'standard input' RECL question...
- Previous by thread: Re: Fortran 2003/2008 features and compiler poll
- Next by thread: Re: Fortran 2003/2008 features and compiler poll
- Index(es):
Relevant Pages
|