size of space to be allocated

Hi!

Is there an easy way to get the size in bytes of an intricate user-
defined type even if there is not yet a variable of this type?

Something like:

INTEGER, PARAMETER :: NMax = 10

TYPE MyType
INTEGER(2), DIMENSION(NMax) :: Values
END TYPE MyType

NBytes = SIZEOF(MyType)

which would yield NBytes = 20

My program protests that I want to allocate too much space and I want
to find out how much I was trying to allocate.

Regards,


Arjan

Arjan wrote:
....
> Is there an easy way to get the size in bytes of an intricate user-
> defined type even if there is not yet a variable of this type?
....
> NBytes = SIZEOF(MyType)
>
> which would yield NBytes = 20
>
> My program protests that I want to allocate too much space and I want
> to find out how much I was trying to allocate.
....

What about allocating one (or a small number) and extrapolating from
there as a kludge?

I'm not sure about the SIZEOF() intrinsic -- it's an extension in the
compiler I use that has some limitations...ottomh I don't know if it
gets user-defined types right under all cases or not. (Simple ones I'm
pretty sure are ok, more complex I'm not sure about.)

--

Arjan <arjan.van.dijk@rivm.nl> wrote:

> Is there an easy way to get the size in bytes of an intricate user-
> defined type even if there is not yet a variable of this type?
....
> NBytes = SIZEOF(MyType)

Certainly not in the standard, and I sort of doubt even most of the
usual extensions. There are various ways to get the size of a data
object, but not just of a type itself. You don't tend to be able to use
a type name as an argument (as in your example).

As soon as you declare a variable of the type, then that's a different
story; several potential ways then, standard and extensions, but I'm
under the impression that you know about them.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

> As soon as you declare a variable of the type, then that's a different
> story; several potential ways then, standard and extensions, but I'm
> under the impression that you know about them.


Apparently not, Richard, please give me some hints!

By the way: I believe that in Pascal the SIZEOF function works with
just a TYPE as arguement.
But then: fortran .NEQ. Pascal...

A.

glen herrmannsfeldt wrote:
> Arjan wrote:
> (snip)
>
>> By the way: I believe that in Pascal the SIZEOF function works with
>> just a TYPE as arguement.
>> But then: fortran .NEQ. Pascal...
>
> In C, the sizeof operator (not function) works with either
> types or variables. Often parentheses are needed, but it
> still isn't a function.

Of course, the distinction is hard to follow without formal
definitions of the terms. In most language semantics discussions,
an operator is just syntactic sugar for a function application.

I've got a copy of the C89 rationale document around here
somewhere. I'm not sure it ever stated *why* sizeof is
considered an operator. Though it may be that they wanted
to allow types as operands, and didn't want to special-case
their description of functions.

Parenthesis are optional only of the operand is a unary-expression.
It's probably good style to use parenthesis anyway.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra

Arjan <arjan.van.dijk@rivm.nl> wrote:

> > As soon as you declare a variable of the type, then that's a different
> > story; several potential ways then, standard and extensions, but I'm
> > under the impression that you know about them.
>
> Apparently not, Richard, please give me some hints!

Oh, I thought your emphasis on using the type without declaring a
variable meant that you knew those ways. Well, lets' see...

1. In f2003, oh, hold on. That's right - that one didn't make it into
f2003. One of my pet peeves that f2003 added new features that applied
only to f77-style stuff. (You could get the size of the f77 kinds, but
that's all). Anyway, the f2008 draft has a storage_size intrinsic. Some
compilers might implement it already, as it is trivial. I think the
f2008 draft also has C_SIZEOF (or some such name), though it is
basically redundant with storage_size.

2. Lots of compilers today have extensions, often called sizeof.

3. The best you can do that is standard conforming today is to use

inquire (iolength=result_variable) data_variable

See any book for details. Although that is standard conforming, it has a
huge number of caveats, some of them subtle. Namely

a) The result is in storage units, which are most commonly, but not
always, bytes. For portability, you can do a separate inquire with data
of known size to deduce what the storage unit size is (or there's the
f2003 named constant for that).

b) A subtle one that bit me once. For what are probably silly reasons
the data_variable has to have a defined value. Yes, that means all the
components. I got bit by that once when I had just made a temporary data
variable with no other purpose and hadn't bothered to give it a value.

c) Related to b is that the data value probably has to be something that
could be written to an unformatted file. That rules out quite a few
types.

d) Another subtle one is that the result isn't strictly defined to be
the size of the variable, but instead the record size required for it.
It is possible for these to differ (for example, if the system has
limitations on allowed record sizes, perhaps requiring a multiple of 4
or some such thing).

4. Other roundabout system-dependent things. One that occurs to me is
that you could write it to a sequential unformatted file and then deduce
the data size from the resulting file size.

None of these will do anything with a type.You need to have a data
object of the type.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Arjan wrote:
(snip)

> By the way: I believe that in Pascal the SIZEOF function works with
> just a TYPE as arguement.
> But then: fortran .NEQ. Pascal...

In C, the sizeof operator (not function) works with either
types or variables. Often parentheses are needed, but it
still isn't a function.

-- glen

Richard Maine wrote:

> Arjan <arjan.van.dijk@rivm.nl> wrote:
>
>
>>>As soon as you declare a variable of the type, then that's a different
>>>story; several potential ways then, standard and extensions, but I'm
>>>under the impression that you know about them.
>>
>>Apparently not, Richard, please give me some hints!
>
>
> Oh, I thought your emphasis on using the type without declaring a
> variable meant that you knew those ways. Well, lets' see...
>
> 1. In f2003, oh, hold on. That's right - that one didn't make it into
> f2003. One of my pet peeves that f2003 added new features that applied
> only to f77-style stuff. (You could get the size of the f77 kinds, but
> that's all). Anyway, the f2008 draft has a storage_size intrinsic. Some
> compilers might implement it already, as it is trivial. I think the
> f2008 draft also has C_SIZEOF (or some such name), though it is
> basically redundant with storage_size.
>

I think that some of these C interoperability additions were done
incorrectly. What if I want to find the Fortran sizeof something?
Naming it C_SIZEOF implies that I might never have a need to do that
(not implying that the result would be different (padding?)). I think I
would have for those things that are potentially useful in Fortran,
would have added an optional argument to a generically named
SIZEOF...(BIND(C),...) (or BIND=C or ...). I don't like sprinkling
unnecessary references to other languages that way just to get that type
of new functionality.


<snip>
--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott <garylscott@sbcglobal.net> wrote:

> I think that some of these C interoperability additions were done
> incorrectly. What if I want to find the Fortran sizeof something?
> Naming it C_SIZEOF implies that I might never have a need to do that
> (not implying that the result would be different (padding?)). I think I
> would have for those things that are potentially useful in Fortran,
> would have added an optional argument to a generically named
> SIZEOF...(BIND(C),...) (or BIND=C or ...). I don't like sprinkling
> unnecessary references to other languages that way just to get that type
> of new functionality.

I probably wrote it a bit messily, making it harder than it ought to be,
but you might want to reread my prior posting. If you want the Fortran
size of something, you use the intrinsic that is there for exactly that.
It is named storage_size. There are reasons why it is not named sizeof,
but that doesn't sound like what you are complaining about. Sounds like
you are complaining that it doesn't exist in the more general form. It
does. Yes, I very much can come up with non-C-related uses for
storage_size; that's why I proposed it.

In fact, you basically never need to use C_sizeof. If I recall
correctly, C_sizeof is completely redundant and can be written in terms
of the more general storage_size. I recall being against adding c_sizeof
because of the redundancy, though I didn't think it a big deal. C_sizeof
is mostly a convenience feature because it is needed so much and it is
slightly long-winded to write in terms of storage_size.

Storage_size gives its result in bits (that being much more general than
assuming everything is in bytes; it is easy to go from units of bits to
bytes, but not so easy the other way if you allow for the possibility
that there might ever be anything that wasn't an integer number of
bytes). Storage_size also gives the size of a scalar of the type, even
if you give it an array argument; in essence, it gives you the size of
the type, even though you can't use the type directly as an argument
(because you can't do that for any arguments in Fortran, and this was
supposed to be a small feature instead of introducing a whole new kind
of argument, which would have major implications all over). So to get
c_sizeof, you need to do something like

storage_size(variable)*size(variable)/8

(or a little fancier if you really want to worry about the possibility
of non-byte sizes).

Long ago, I think it used to be that there were restrictions on
storage_size such that there might be bind(c) types you couldn't use it
on. But I think those went away.

No, C_sizeof is not about different padding or anything of the sort and
it doesn't need any such thing. Putting a bind(c) on the derived type
definition can change the padding, but once you have a type... well...
you then have that type. It doesn't have multiple versions for bind(c)
versus non-bind(c). It just either is bind(c) or it is not. You might
have 2 different types, one with bind(c) and one without. But if so,
those are just different types.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

James Giles wrote:
(snip on sizeof function or operator)

> Of course, the distinction is hard to follow without formal
> definitions of the terms. In most language semantics discussions,
> an operator is just syntactic sugar for a function application.

Mostly that the parenthesis needed for a function call
aren't needed for sizeof.

> I've got a copy of the C89 rationale document around here
> somewhere. I'm not sure it ever stated *why* sizeof is
> considered an operator. Though it may be that they wanted
> to allow types as operands, and didn't want to special-case
> their description of functions.

Function call is also an operator. You can apply () to
anything of the appropriate type, even the return value
from a function. (Not that I have ever tried the latter.)

> Parenthesis are optional only of the operand is a unary-expression.
> It's probably good style to use parenthesis anyway.

I usually do. sizeof(struct xyz), sizeof(long double),
sizeof(a+b).

-- glen