size of space to be allocated

"Richard Maine" <nospam@see.signature> wrote in message
news:1im0yyx.3dluor1t5a1tyN%nospam@see.signature.. .

> 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.

? I will assume that you are just trolling for an example:

C:\gcc_mingw64\clf\sizeof>type sizeof.f90
program sizeof
INTEGER, PARAMETER :: NMax = 10

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

integer NBytes

!NBytes = SIZEOF(MyType)
NBytes = size(transfer(MyType(0),int((/0/),selected_int_kind(2))))
write(*,'(a,i0)') 'NBytes = ', NBytes
end program sizeof

C:\gcc_mingw64\clf\sizeof>gfortran sizeof.f90 -osizeof

C:\gcc_mingw64\clf\sizeof>sizeof
NBytes = 20

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk <not_valid@comcast.net> wrote:

> ? I will assume that you are just trolling for an example:
[of how to compute the size of a variable]
....
> NBytes = size(transfer(MyType(0),int((/0/),selected_int_kind(2))))

Oh yeah. I was thinking there were some more ways that weren't comming
to me off the top of my head. That's one.

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

Hello,

storage_size() returns the size in bits,
including padding for alignment of array elements.

c_sizeof() returns the size in bytes,
as bytes are defined by the companion processor.

They are hardly redundant, as the relevant bytes
are a function of the companion processor,
and, most likely, of the options set on the companion processor.

Specifically, if the companion processor is a C compiler
with options set to make 32-bit characters default,
then c_sizeof() returns the size in 32-bit words, and so on.

storage_size() is intended to allow a programmer to catch
odd sizes used for any object. c_sizeof() is intended
to allow calling C functions, with the customary
( starting-address, number-of-bytes) calling sequence.

Different intentions, different measuring units, different uses.
Related, perhaps, but hardly redundant.

On 2008-08-21 21:28:10 -0400, nospam@see.signature (Richard Maine) said:

--
Cheers!

Dan Nagle

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:
> (snip)
>
> > 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.
>
> Many systems now allocate uninitialized memory by setting page
> table entries to point to a single page of zeros, using copy
> on write to allocate pages when it is actually modified.
>
> While I wouldn't expect this to bother storage_size, it
> does change some benchmark timing. Also, it has the surprising
> effect that you might not be notified at allocation time
> that insufficient (virtual) storage is available, but it
> can fail when you actually try to use it.

The cited problem related to inquire rather than the proposed
storage_size intrinsic. The storage_size intrinsic (in any of its
proposed variants) does *NOT* have such a requirement.

And while I thought it a subtle requirement for inquire, the failures
were related to nothing quite that subtle. It was just detected at
compile time as a reference of an undefined variable. SInce the variable
was a simple local variable that wasn't used for anything else, it was
one of the cases where it was easy for the compiler to deduce this at
compile time.

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

Dan Nagle wrote:

> storage_size() returns the size in bits,
> including padding for alignment of array elements.

> c_sizeof() returns the size in bytes,
> as bytes are defined by the companion processor.

> They are hardly redundant, as the relevant bytes
> are a function of the companion processor,
> and, most likely, of the options set on the companion processor.

In C, the preprocessor symbol CHAR_BIT is available
to indicate the system specific number of bits
for a char variable. By definition, sizeof(char) is 1.

> Specifically, if the companion processor is a C compiler
> with options set to make 32-bit characters default,
> then c_sizeof() returns the size in 32-bit words, and so on.

If unicode gets more popular, I might expect 16.
The char type in Java is unsigned 16 bit, the only
unsigned type in Java.

-- glen

Richard Maine wrote:
(snip)

> 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.

Many systems now allocate uninitialized memory by setting page
table entries to point to a single page of zeros, using copy
on write to allocate pages when it is actually modified.

While I wouldn't expect this to bother storage_size, it
does change some benchmark timing. Also, it has the surprising
effect that you might not be notified at allocation time
that insufficient (virtual) storage is available, but it
can fail when you actually try to use it.

-- glen

On Fri, 22 Aug 2008 00:23:58 GMT, "James Giles"
<jamesgiles@worldnet.att.net> wrote:

> glen herrmannsfeldt wrote:

> > 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.
>
And function notation can be sugar (or pepper?) for things I for one
think of as operators, e.g. SQRT() ABS() CMPLX(X,Y).
Or my probably all-time unfavorite, PL/I's SUBSTR().

But the formal difference is that operator symbols like + and && and
sizeof are reserved -- sizeof is a keyword -- and cannot be anything
else. Functions are 'just' named routines and those names can be
reused at least within (some) scopes. (Though standard C doesn't
guarantee you the ability to override a standard routine with your
own, as Fortran does if explicitly EXTERNAL, many implementations
support it just by linking your code before the library.)

In Fortran keywords aren't reserved, so this vanishes.

> 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.
>
Very likely. Back in the early days, when as much as possible --
including all I/O, and nearly all string handling -- was sloughed off
into the library (and not recognized hence not optimized by the
compiler) to make the compiler work in perhaps 16KB on a PDP-11,
sizeof had to stay in the compiler. Not only can't you pass a type
itself as an arg at all, but you can't pass-by-value an arbitrary
(undescribed) type and expect an out-of-line function to deal with it.

> Parenthesis are optional only of the operand is a unary-expression.

Which is usually but not necessarily a (single) variable.

> It's probably good style to use parenthesis anyway.

Yeah. It's not like they cost $150 per barrel or something. <G>

- formerly david.thompson1 || achar(64) || worldnet.att.net

On Aug 21, 5:23*pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> I've got a copy of the C89 rationale document around here
> somewhere. *I'm not sure it ever stated *why*sizeofis
> 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.

The original K&R C language had no intrinsic functions, only the
ability to call external library functions plus a description of the
ones that the C library was obligated to provide. (As in Fortran, the
practical distinction between intrinsic and external is that in a
separate-compilation environment, an external function can't be
implemented inline if the user expects to be able to replace it with
his own at link time.)

Although C89 adds rules to allow the the implementor to provide the
standard functions inline, it still permits a conforming compiler to
implement them via an external library. Since "sizeof" can't be
implemented via an external library, it had to be an operator.

To me, the optionality of the parens seems less mysterious if I think
that "sizeof", like any other operator, never takes parens. When its
operand is an expression, the expression may or may not provide
parens; when its operand is a "cast", the cast always provides parens
because without them it wouldn't be a cast.

Steven Correll <steven.correll@gmail.com> wrote:

> ... C library ... (As in Fortran, the
> practical distinction between intrinsic and external is that in a
> separate-compilation environment, an external function can't be
> implemented inline if the user expects to be able to replace it with
> his own at link time.)

In Fortran at least, there are much more important practical
distinctions than that. External procedures can sometimes be inlined;
there exist compilers that do so. The above "if the user expects..."
makes your statement true, but that's a significant qualification.

More fundamental is that intrinsics may be used for some things where
user procedures are not allowed - notably in initialization expressions.
Initialization expressions are designed to be doable at compile time
(even though the standard doesn't use thsoe words).

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

On Sep 5, 9:37*am, nos...@see.signature (Richard Maine) wrote:
> StevenCorrell<steven.corr...@gmail.com> wrote:
> > ... C library ... (As in Fortran, the
> > practical distinction between intrinsic and external is that in a
> > separate-compilation environment, an external function can't be
> > implemented inline if the user expects to be able to replace it with
> > his own at link time.)
>
> In Fortran at least, there are much more important practical
> distinctions than that. External procedures can sometimes be inlined;
> there exist compilers that do so. The above "if the user expects..."
> makes your statement true, but that's a significant qualification.
>
> More fundamental is that intrinsics may be used for some things where
> user procedures are not allowed - notably in initialization expressions
> ...

It's useful to be reminded of other aspects of Fortran intrinsics even
if they don't relate to the question "Why isn't C sizeof a function?".
I hoped my phrase "separate-compilation environment" would be
understood to rule out inlining, but evidently not, so I had better
say exactly what I meant: a compiler which is not permitted to see the
entire program at once can still opt to inline an intrinsic, but it
cannot inline an external procedure in the compiler library if that
procedure might be defined in the unseen part.

While my "if the user expects to replace" may seem a quirk, it's at
the heart of the history that explains why "sizeof" isn't a function:

1. Kernighan and Ritchie implemented the original C as a simple
translator emitting code for operators and control flow constructs,
but relying on a "standard C library" for everything that could be
implemented via external functions. Since it couldn't be implemented
via an external function, "sizeof" was an operator. That
implementation remained the de facto definition of C till C89.

2. Users wrote applications which relied on replacing standard C
library functions with their own (occasionally discovering to their
dismay that the library could not provide function X without
duplicating a user-replaced Y.) Compiler-writers confronted the
dilemma of wanting to emit some standard functions inline, but not
wanting to break existing applications in situations where the
compiler is "blind" to part of the program.

3. The C89 standards committee reserved the identifiers provided by
the "standard C library", permitting its functions to be emitted
inline even if the translator is "blind" to part of the program. (As a
concession to existing practice, they described a mechanism by which
implementors could opt to support (2) while still conforming.)

4. Taking advantage of the C89 standard, C compilers today often emit
code inline for a standard C library function like "memcpy" even if
they are "blind" to parts of the program, so in this respect "memcpy"
is now almost as intrinsic as "sizeof", and if one doesn't know the
history of 1-3, it's logical to ask why "sizeof" isn't a function like
"memcpy."

I'm not sure anybody really cares this much, but the standard is at
http://rm-f.net/~orange/devel/specif.../c89-draft.htm and the
rationale is at http://www.lysator.liu.se/c/rat/d1.html; look for the
section "Use of Library Functions" and follow the references from
there.