Prev: GCC/gfortran 4.5.0 release
Next: linking not done
From: FX on 16 Apr 2010 16:48
>> It would be much more useful if the standard required the compiler to
>> accept lines of any length. After all, the standard places no restriction
>> on the number of lines in the program, why should it have a restriction
>> for columns (other than historical reasons)?
>
> When they start making computers with an infinite amount of
> memory, then they might do that.

Please address the unnatural dissimilarity between lines and numbers.

The standard, as far as I understand, does not place a limit on number of
lines (or total program length). By the same arguments you use, that
would be a deficiency of the standard.

--
FX
From: glen herrmannsfeldt on 16 Apr 2010 18:11
FX <coudert(a)alussinan.org> wrote:
>>> It would be much more useful if the standard required the compiler to
>>> accept lines of any length. After all, the standard places no restriction
>>> on the number of lines in the program, why should it have a restriction
>>> for columns (other than historical reasons)?

>> When they start making computers with an infinite amount of
>> memory, then they might do that.

> Please address the unnatural dissimilarity between lines and numbers.

> The standard, as far as I understand, does not place a limit on number of
> lines (or total program length). By the same arguments you use, that
> would be a deficiency of the standard.

Not on total length, but systems may restrict it.

Fortran 2003 free form has a limit of 255 continuation lines, of,
as noted, up to 132 characters, limiting a single statement to
about 256*131 characters. (Allowing for & at the end of each line.)

That is a lot less than infinity, and allows one to plan buffer
sizes appropriately.

As Richard says, these numbers, as required by the standard, are
minimums for a standard implmentation. As extensions to the standard,
an implmentation may have larger limits.

On many, the total program length limit depends on the available
memory. It may be big or small depending on the size of a
specific system.

-- glen

From: Gordon Sande on 16 Apr 2010 18:22
On 2010-04-16 17:48:27 -0300, "FX" <coudert(a)alussinan.org> said:

>>> It would be much more useful if the standard required the compiler to
>>> accept lines of any length. After all, the standard places no restriction
>>> on the number of lines in the program, why should it have a restriction
>>> for columns (other than historical reasons)?
>>
>> When they start making computers with an infinite amount of
>> memory, then they might do that.
>
> Please address the unnatural dissimilarity between lines and numbers.
>
> The standard, as far as I understand, does not place a limit on number of
> lines (or total program length). By the same arguments you use, that
> would be a deficiency of the standard.

Isn't it the case that an (very poor quality) implementation could reject
a two line program as being too complex although each line could be 132
characters long and still be conforming.

Realistically even a high quality implementaion might reject a 100,000,000 line
subroutine. Noone objects to compilers that can not generate 50GB of
object code.
It seems that you have missed the substance of Richards comments about how to
understand "standard speak" with its inverted uasge. Back when 640KB
more memory
than anyone might ever want there were conforming compilers that rejected
subroutines of several thousand lines as being too complex as the generated
object code was too large for the addressing mechanisms of the processor.

The standard tells the user the maximum that the user can use before
the compiler
might be allowed to complain about the complexity. Thus the users
maximum is the
compilers minimum. Just like Richard told you.







From: glen herrmannsfeldt on 16 Apr 2010 18:25
FX <coudert(a)alussinan.org> wrote:
(snip)

> The standard, as far as I understand, does not place a limit on
> number of lines (or total program length). By the same arguments
> you use, that would be a deficiency of the standard.

I just noticed the requirement in fixed form that the END statement
not be continued. Presumably it is sometimes hard for the system
to recognize the END statement, though I have known systems in
the past that allowed it.

So, I tried it with gfortran. It seems that gfortran doesn't
allow the last statement to be a continued END, except
that it does allow it if it is followed by another statements,
such as SUBROUTINE.

-- glen

From: Richard Maine on 16 Apr 2010 20:07
FX <coudert(a)alussinan.org> wrote:

> It would be much more useful if the standard required the compiler to
> accept lines of any length.

Then there would be no standard conforming compilers - ever. That is not
possible.

Note in this regard that the standard doesn't actually say "compiler".
For most purposes, we can ignore that, as it is a whole lot easier to
just say "compiler" than to use the standard's "processor" terminology
(with the necessary footnote about "processor" not meaning the same
thing as most people will naturaly read it to mean.)

But for the current question, the distinction is very relevant. The
standard's limitations are actually on the whole "processor", which
includes all the software and hardware necessary to make Fortran code
run. Thus, if the standard required support of infinite line size, the
vendor could not use the excuse that the finite limits are in the
operating system or hardware instead of in the compiler. If the system
taken as a whole did not allow infinite line size, then it would not be
standard conforming.

Yes, that is exactly how such a requirement would be interpreted in
standard-speak.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: GCC/gfortran 4.5.0 release
Next: linking not done