Re: another way to shoot yourself in the foot?

[nospam@see.signature (Richard Maine)]

fj <francois.jacq@irsn.fr> wrote:

> On 10 juil, 16:10, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
> wrote:

> > Could Fortran 90 allocatables be left in an undefined state?
> 
> No. Either an allocatable is allocated or not.

That is true now, but wasn't so in f90, which the question specifically
asked about. But then, this is one of the many things in the set of
questions (at least now I can read them) that strike me as being either
out of context or otherwise irrelevant to current programming. This was
true only of f90. Prior to f90, there were no allocatables. In f95, this
"feature" was fixed. You won't find any f90 compilers currently being
supported today. If you manage to find some old compiler that still has
this issue, and you are using that compiler, then I think that pretty
conclusive evidence that you don't care about "minor" issues like
reliability and support. All quality compilers with active support were
long ago upgraded.

My question in return is why anyone would be asking this other than as
flame material? It was quite explicit in the citation (which was mine,
by the way) that this was an f90 feature fixed in f95.

I'll not elaborate on details of several of the other questions. The
answers Francois gave are at least good enough, if they aren't quite the
way I would have answered. Several of them seem to fall in the
categories of either:

1. Does some random compiler have some random bug or misfeature
(including the lack of an important feature)? These have a lot the
flavor of scouring the newsgroup for negative things. I'll give the
general answer that, yes some compilers have some bugs and misfeatures.
I'll add that some compilers are worse about this than others. I'll also
add that this answer is completely non-Fortran specific. It applies
equally well, for example, to C, C++, Ada or any other language that is
more than trivial. I will ignore requests for examples or claims that it
isn't true of some language. That avenue of usenet discussion has no
constructive end - just flames. While it is no doubt the case that some
languages have a higher frequency of compiler bugs than others and that
there might be some lessons to be learned from that, frankly the odds of
such constructive data comming out of a usenet discussion like this are
zero. To be anything cloise to useful, such a thing would actually
require comprehensive study rather than just random samples of things
that people happened to post.

or

2. Does Fortran do the impossible? Things that apply to essentially all
languages, but with the question phrased as though it were a
Fortran-specific matter. This also has the look of just skimming the
newsgroup for things that sound negative. For one example, no Fortran
doesn't check all array bounds "at compile time". That is inherently
impossible in any language unless it is so limitted as to be useless.
Array index values can be a function of input data, which is not
available at compile time. If a language didn't allow such input data,
it would be in the category of so limitted as to be useless. Checking
some bounds at compile time is practical and is often done. Checking all
bounds at run-time is practical in many cases and is often done.
Checking all bounds at compile time is essentially nonsensical. Phrasing
this as a Fortran matter smacks of flaming and pulling things out of
context. (The context lost is that this is not Fortran-specific).

or

3. If you ignore advice about good programming practices, can you get in
trouble? The answer, of course, is yes. That's why they are good
programming practices. Several of the questions appear to be pulled from
explanations of why some programming practices are good, but the context
of the good practices was omitted, leaving just the negative part of
what can happen if you ignore all the good advice.

Quite a lot of the questions fall into those 3 categories. In fact,
skimming them, I'd say that most do. If these are the kinds of questions
being raised in your attempts to evaluate languages, then the effort is
doomed from the start. You won't get useful results starting from
questions like these. It is so much the wrong direction that I can't
even offer constructive criticism other than to throw everything out and
start from scratch with an open mind. I just can't imagine getting there
from this starting point.

This will be my last post in this thread. I see no constructive benefit
to posting further. I was pulled into posting this one by the factual
error in the answer about undefined allocatable state. (The answer is
correct for today, but was not correct specifically for f90). I've gone
on for far more than I really ought to have already. It would take quite
a bit longer to give detailed answers and elaborations to each question,
but I don't see the benefit of doing so.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain