Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen say
... Why was the storage_size function added, and what are its practical applications?
On Wednesday, February 16, 2022 at 11:10:28 AM UTC-5, g...@pobox.com wrote:Its useful for any number of bit manipulation tasks that you want to
Beliavsky <beli...@aol.com> writes:
Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen say >>>
... Why was the storage_size function added, and what are its practical applications?
Near as I can tell digging through the old J3 Fortran papers, it was
introduced in paper 04-120.txt at meeting 167 (link
https://j3-fortran.org/doc/year/04/04-120.txt).
There are a number of other papers where storage_size is refined or
mentioned. bu I did not dig deeply into them.
Here is the text of the 04-120.txt rationale:
Rationale: Storage size in bits is a low level concept which ordinarily
I would prefer to leave unspecified in standard Fortran. However,
there are programmers who need to write extremely portable programs
that depend on the exact sizes of data items. F03
already specifies that a programmer has access to the sizes
of the standard-specified storage units. This proposal
extends the programmer's access to size information
to the case of derived types and intrinsic types not required
to be supported (a seconmd integer kind or a third real kind,
for example).
Following the arguments made for the storage size constants
in ISO_FORTRAN_ENV, the size is specified in bits to enable
detection of unusual hardware or of unusual software conventions.
STORAGE_SIZE results should be available during compilation
to enable array extents to be declared, etc.
STORAGE_SIZE should reside in ISO_FORTRAN_ENV because that's
where the constants are, and it seems to be
an environment-oriented inquiry.
Helpful, thanks. Maybe storage_size is useful when calling C? I'm
aware of the ISO_C_BINDING module.
Beliavsky <beli...@aol.com> writes:
Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen say
... Why was the storage_size function added, and what are its practical applications?
Near as I can tell digging through the old J3 Fortran papers, it was introduced in paper 04-120.txt at meeting 167 (link https://j3-fortran.org/doc/year/04/04-120.txt).
There are a number of other papers where storage_size is refined or mentioned. bu I did not dig deeply into them.
Here is the text of the 04-120.txt rationale:
Rationale: Storage size in bits is a low level concept which ordinarily
I would prefer to leave unspecified in standard Fortran. However,
there are programmers who need to write extremely portable programs
that depend on the exact sizes of data items. F03
already specifies that a programmer has access to the sizes
of the standard-specified storage units. This proposal
extends the programmer's access to size information
to the case of derived types and intrinsic types not required
to be supported (a seconmd integer kind or a third real kind,
for example).
Following the arguments made for the storage size constants
in ISO_FORTRAN_ENV, the size is specified in bits to enable
detection of unusual hardware or of unusual software conventions.
STORAGE_SIZE results should be available during compilation
to enable array extents to be declared, etc.
STORAGE_SIZE should reside in ISO_FORTRAN_ENV because that's
where the constants are, and it seems to be
an environment-oriented inquiry.
On 2/16/2022 10:41 AM, Beliavsky wrote:
On Wednesday, February 16, 2022 at 11:10:28 AM UTC-5, g...@pobox.com wrote: >>> Beliavsky <beli...@aol.com> writes:Its useful for any number of bit manipulation tasks that you want to
Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen say >>>>
... Why was the storage_size function added, and what are its practical applications?
Helpful, thanks. Maybe storage_size is useful when calling C? I'm
aware of the ISO_C_BINDING module.
make semi-portable.
Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen sayunlimited polymorphic. The return type is integer with the specified kind, or default kind if kind is not present.
storage_size (a [, kind ] ) returns the size, in bits, that would be taken in memory by an array element with the dynamic type and type parameters (Section 15.3.2) of a.
The argument a may be of any type or rank (including a scalar). It is permitted to be an undefined pointer unless it is polymorphic, and is permitted to be a disassociated pointer or unallocated allocatable unless it has a deferred type parameter or is
On Thursday, February 17, 2022 at 1:09:05 AM UTC+11, Beliavsky wrote:is unlimited polymorphic. The return type is integer with the specified kind, or default kind if kind is not present.
Fortran 2008 introduced the storage_size function. Metcalf/Reid/Cohen say
storage_size (a [, kind ] ) returns the size, in bits, that would be taken in memory by an array element with the dynamic type and type parameters (Section 15.3.2) of a.
The argument a may be of any type or rank (including a scalar). It is permitted to be an undefined pointer unless it is polymorphic, and is permitted to be a disassociated pointer or unallocated allocatable unless it has a deferred type parameter or
I have struggled with the use of STORAGE_SIZE, especially when
trying to document the storage size of a derived type that contains allocatable array components, especially when trying to report
the size of an array of the derived type. It can be difficult to
identify the actual memory storage/usage of this structure, which
would be preferred in bytes. SIZE and SIZE_OF are also available
but exclude derived type data structures.
This problem arose when trying to document the memory usage
growth of an Allocatable derived type array where each derived
type included 1d and 2d allocatable arrays.
Allocatable components also store their allocated status and size.
As David Duffy identified, "esp in the case of a later crash"
eg Documenting the memory usage of structure
"element_array_records" as it grows (and may need to be extended)
module ELEM_DATA_BASE
TYPE elem_data_record
...
TYPE elem_array_record ! set in elcomp
integer*4, allocatable :: ln(:) ! (ni) element parameters
What about something like^^^^^^^
program main
implicit none
integer, parameter :: ip = selected_int_kind(15)
type foo
real, dimension(:), allocatable :: a
real, dimension(:,:), allocatable :: b
end type foo
type(foo), allocatable, dimension(:) :: x
allocate (x(2))
allocate (x(1)%a(1234))
print *,foo_size(x)
contains
integer(kind=ip) function foo_size(arr) result(res)
type(foo), dimension(:), intent(in) :: arr
integer(kind=ip) :: sz
integer(kind=ip) :: i
sz = size(arr)
res = sz * storage_size(arr)
do i=1,sz
if (allocated(arr(i)%a)) &
res = res + storage_size(arr(i)%a(1)) * size(arr(i)%a)
if (allocated(arr(i)%b)) &
res = res + storage_size(arr(i)%b(1,1)) * size(arr(i)%a)
Thomas Koenig <tko...@netcologne.de> schrieb:
What about something like
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:10:59 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,574 |