Prev: do_ud: end of file
Next: Pointers and dynamic data structures in Fortran 90/95
From: H?kan on 3 May 2006 18:27
Hello,

I would like to know how many bytes a certain datatype (e.g. real) takes
up on the system. I understand that this is machine dependent. What
command would I use to find that out?

Regards.
From: Michael Metcalf on 3 May 2006 09:38

"H?kan" <H.L(a)aracer.com> wrote in message news:44592E5B.1935(a)aracer.com...
> Hello,
>
> I would like to know how many bytes a certain datatype (e.g. real) takes
> up on the system. I understand that this is machine dependent. What
> command would I use to find that out?
>

You can use inquire by I/O list, as in

integer length
inquire(iolength=length) list

where list is your variable(s). Note that length is in processor-dependent
units, but it's usually in bytes and whether or not it is, is pretty obvious
from its value.

HTH,

Mike Metcalf


From: Richard E Maine on 3 May 2006 11:34
Michael Metcalf <michaelmetcalf(a)compuserve.com> wrote:

> "H?kan" <H.L(a)aracer.com> wrote in message news:44592E5B.1935(a)aracer.com...
> >
> > I would like to know how many bytes a certain datatype (e.g. real) takes
> > up on the system. I understand that this is machine dependent. What
> > command would I use to find that out?
>
> You can use inquire by I/O list...

Yes. That's probably the most portable method in practice today. And you
can even automatically determine the compiler-dependent units of measure
with a little trickery involving comparison with the intrinsic function
bitsize applied to a default integer; I don't think I ever needed to
resort to that particular trick, but it should work.

There are some other caveats about such inquires. They are probably
mostly caveats in theory instead of in practice, but still they make me
uneasy and are part of why I was one of the people pushing for better
solutions in later standards (see below).

Fundamentally, the problem with this inquire is that it inquires about
I/O properties instead of about memory properties. While the two are
usually the same, it ain't necessarily always the case. In particular, I
would be concerned about systems where record sizes might not be allowed
to be a completely arbitrary number of bytes. The I/O inquiry just gives
a record size large enough to hold the variable; it doesn't guarantee
that there is no padding in there.

And then there are some derived types that you can't directly do
unformatted I/O on, so the technique doesn't apply to them at all.

As of f2003, the standard provides an answer for a very few special
cases. See the named constants character_storage_size and
numeric_storage_size (plus file_storage_size) in the iso_fortran_env
intrinsic module. I personally found it strange that f2003 added
material that supports only the f77 cases, ignoring f90/f95. For
example, there is no comparable way to inquire about the size of a
non-default integer kind, or a real that isn't either default or double.
And it does nothing for derived types other than the special cases of
numeric or character sequence types. I bitched rather loudly about these
limitations (and haven't stopped, as you can see :-)) and pushed to
replace (or supplement) this with a more general facility, but I lost
that one (by being too late in the process).

My proposed facility, which didn't make it into f2003, probably will be
in f2008. It is an intrinsic function named storage_size. Actually, I
think most compilers already have comparable facilities, but the
spellings vary.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
From: gary.l.scott on 3 May 2006 11:51
"storage_size" probably isn't the best spelling. I mostly think of
"storage" as referring to disk space. "memory_size" might have been a
little better, but still not quite right.

From: Dan Nagle on 3 May 2006 12:07
Hello,

gary.l.scott(a)lmco.com wrote:
> "storage_size" probably isn't the best spelling. I mostly think of
> "storage" as referring to disk space. "memory_size" might have been a
> little better, but still not quite right.

It's the size within a storage sequence.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
 |  Next  |  Last
Pages: 1 2
Prev: do_ud: end of file
Next: Pointers and dynamic data structures in Fortran 90/95