Re: Allocating arrays inside a subroutine.

Richard E Maine wrote:
deltaquattro wrote:
Fortran 90 and 95 were designed originally for such things to be
done with pointers... Most of us think that this was a
design mistake. It was later corrected (in the f95 allocatable TR
and in 2003), but these are not yet universally supported, so we are
still suffering from the original bad decision 15 years later.

and Jan Vorbrüggen <jvorbrueggen@xxxxxxxxxxxxxxx> replied:

As I understood Richard Maine, they wanted to get F90 and F95 out in time
- well, no later than they were already - and thought they needed more time
to think through all the ramifications of making the extensions described
in the TR. That seems like a wise decision to me.

Jan has accurately summarized what I recall as being the situation for
f95. I'll note that it has taken a long time for compilers to get all
the corners of the TR implemented correctly (and some haven't done it
yet), confirming in my mind that it isn't as trivial a matter as some
might think.

I think the situation in f90 was different. I was not there during the
development of f90, so I can't report first hand. But my second-hand
impression is that delquattro's description might have been accurate for
f90. The desirability of enhancing allocatables to fill the role was
certainly known during f95 development, but as Jan says, it was slow
work. So I think there are elements of truth in both the above versions
of things, depending on whether you are talking about f90 or f95.

Now, not including the capability to initialize a POINTER to NULL() in F90,
_that_ was a mistake.

I think you misdescribe the issue. First, note that you *CAN* initialize
a pointer to null() in f90. The statement

integer, pointer :: p => null()

is perfectly fine f90. I can imagine two things you might possibly be
referring to.

Are you sure about this? Reading M&R (sec. 11.2.8), they say that NULL is a new
intrinsic, introduced in F95. So it seems there are two issues here: default
initialization of derived-type components, AND the introduction of the NULL
intrinsic.

Of course, you could be right and M&R could be wrong. Given how much both you
and M&R know about Fortran, deciding between the two options is a classic
"immovable object/irresistible force". Not that I'm implying you're
irresistible, of course. :)

cheers,

Rich


1. Some people advocated for pointers to be initialized to null() by
default, without requiring the above syntax. While I can see arguments
for that, note that the existing situation is directly comparable to
that for non-pointer variables, both in the abstract and in
implementation. In both cases they are initially undefined and the
compiler doesn't actually have to do anything special. I won't try to go
further on this matter, but I suspect you would find people on both
sides of it.

2. You might be talking about the (unfortunately named) concept of
default initialization introduced in f95. (It is unfortunately named
because it is not a default for "normal" initialization, but rather is
something that happens in different circumstances from "normal"
initialization; I've had to explain this to many people and I've found
the terminology to be working against me.) Default initialization was
widely agreed to be a concept that f90 badly needed. The
ISO_VARYING_STRING module example implementation painfully showed the
problems caused by the lack of such a feature, as did many user
applications. However, that isn't actually anything very specific to
pointers. Some of the high-profile examples of the problem, including
ISO_VARYING_STRING, happened to involve pointers, but the pointerness
was not the crux of the problem. The problem applies to derived type
components in general - pointer and non-pointer ones.

Adding default initialization was one of the very few new features of
f95. Mostly f95 was aimed at clarifications and corrections. Default
initialization was probably the highest priority of its few new
features.

.

Relevant Pages

  • Re: Allocating arrays inside a subroutine.
    ... It was later corrected (in the f95 allocatable TR ... I think the situation in f90 was different. ... Some people advocated for pointers to be initialized to nullby ... because it is not a default for "normal" initialization, ...
    (comp.lang.fortran)
  • Re: save attribute for module variables
    ... > We have three different kinds of initialization: ... The case of explicit initialization is a classic. ... note that it was added in f95. ... clarifications of things that arose as f90 interpretations. ...
    (comp.lang.fortran)
  • Re: gfortran read of hex values
    ... I think, by F95, it has a right to object. ... REAL and even LOGICAL were forbidden in f95 initialization ... expressions is so inclusive that it will break compilers ...
    (comp.lang.fortran)
  • Re: CFO: Why C?
    ... so that debugging is required and both debugging and maintenance will ... If you anyway are going to write to the memory ... It also can collect all variables, which deserve initialization, so ... from the use of pointers. ...
    (comp.os.linux.development.apps)
  • Re: warn about implicit SAVE?
    ... there is an initialization on the line we're talking about. ... else it would be in the language already. ... it's plausible that people might find uses for many redundant ... I have no idea what you'll use all those pointers for, ...
    (comp.lang.fortran)