Are there any drawbacks of omitting shape specifications in array initiation and operation?

```
real :: x(5), y(5), z(5)
!without shape specification
x = 1e-1
y = 2e-1
z = x + y
!with shape specification
x(:) = 1e-1
y(:) = 2e-1
z(:) = x(:) + y(:)
```

Are there any drawbacks of omitting shape specifications in array initiation and operation?

```
real :: x(5), y(5), z(5)
!without shape specification
x = 1e-1
y = 2e-1
z = x + y
!with shape specification
x(:) = 1e-1
y(:) = 2e-1
z(:) = x(:) + y(:)
```

I prefer writing `x`

to `x(:)`

when the whole array is being referenced. The pros and cons of the two syntaxes are discussed here. Writing just `x`

is more concise and may sometimes lead to a faster program, but writng `x(:)`

on the LHS prevents accidental allocation upon assignment.

3 Likes

For the program

```
integer, allocatable :: vec(:)
allocate (vec(2))
vec(:) = [1,4,9]
print*,vec
vec = [1,4,9]
print*,vec
end
```

`ifort -stand:f18 -check:bounds alas.f90`

gives at run-time

`forrtl: severe (408): fort: (10): Subscript #1 of the array VEC has value 3 which is greater than the upper bound of 2`

so if the programmer wants to assign `vec`

without allowing it to change size, writing `vec(:)`

on the LHS is preferred.

Compiled with `gfortran -std=f2018 -Wall -Wextra -fbounds-check -g alas.f90`

the program output is

```
1 4
1 4 9
```

Is there a compiler option such that gfortran gives a run-time error where Intel Fortran does?

2 Likes