allocate() initialization
Gib Bogle
Uno
> Should one rely on allocated arrays being initialized to zero?
I brushed a thick layer of dust off MR&C and was largely unsuccessful in
a similar endeavor.
What does one need to do to set all of an object's attributes to zero?
--
Uno
Richard Maine
> Should one rely on allocated arrays being initialized to zero?
No. Nowhere does the standard even hint at such a thing.
Even on compilers that initialize static arrays to zero, either by
happenstance or as a "feature", your odds of it happening to act that
way for allocated arrays are probably low. The compiler would likely
have to actively insert code to zero the array because it likely is
using memory that was formerly used for something else.
I recommend against relying on such nonstandard features at all. Code
that uses such features quite commonly needs to be fixed later for one
reason or other, and it is sometimes a lot of work to fix - hugely more
work than it would have been to just explicitly initialize things
properly in the first place. I often take such failure to explicitly
initialize as indicative of failure to think about what the program
needs, which sometimes is more than just initializing variables to zero.
In the case of allocated arrays, odds are fairly high that it just won't
work at all.
One thing that does happen when an array is allocated is default
initialization. But default initialization applies only to derived
types. It is specified in the type definition.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Richard Maine
> What does one need to do to set all of an object's attributes to zero?
That doesn't even make sense. Most attributes aren't numeric at all and
aren't "settable" during execution. I can only suppose you mean
something other than "attribute", but I can't guess what it would be.
m_b_metcalf
> I brushed a thick layer of dust off MR&C and was largely unsuccessful in
> a similar endeavor.
>
undefined variables'.
Regards,
Mike Metcalf
robin
| Should one rely on allocated arrays being initialized to zero?
Nothing is ever initialized to zero automatically.
Colin Watters
"robin" <rob...@dodo.com.au> wrote in message
news:4bcdd1a5$0$893$c30e...@exi-reader.telstra.net...
Rubbish.
See for example the compiler option "-zero" on Intel Fortran.
--
Qolin
Email: my qname at domain dot com
Domain: qomputing
Gordon Sande
>
> "robin" <rob...@dodo.com.au> wrote in message
> news:4bcdd1a5$0$893$c30e...@exi-reader.telstra.net...
>> "Gib Bogle" <g.b...@auckland.no.spam.ac.nz> wrote in message
>> news:hqjgq0$iad$1...@speranza.aioe.org...
>> | Should one rely on allocated arrays being initialized to zero?
>>
>> Nothing is ever initialized to zero automatically.
>>
>>
>
> Rubbish.
>
> See for example the compiler option "-zero" on Intel Fortran.
>
> http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/index.htm
The
>
qualifiers you seemed to have missed are local and scalar in addition
to the fact
that this is for one compiler only. There is also the technical question of the
interaction with the saved attributes as the option is only for variables that
have been saved but not otherwise initialized according to the cited page.
Allocated arrays are not scalars and not local. The option does not exist on
all compilers. The fact that it is an option should have been a loud and clear
warning that this is feature to only be used in duress, such as a
poorly written
legacy code and even then it will not be of much help as there the problem
is often the assumption that variables are saved without having been declared
as such. That is why some compilers offer to initialize all local variables
to zero and forcing the save atribute for all variables (see save
option for Intel).
One can not but help notice that the legacy problems often arise from the sort
of misreading with jumping to conclusions that your comment typifies.
Gib Bogle
> Gib Bogle <g.b...@auckland.no.spam.ac.nz> wrote:
>
>> Should one rely on allocated arrays being initialized to zero?
>
> No. Nowhere does the standard even hint at such a thing.
>
> Even on compilers that initialize static arrays to zero, either by
> happenstance or as a "feature", your odds of it happening to act that
> way for allocated arrays are probably low. The compiler would likely
> have to actively insert code to zero the array because it likely is
> using memory that was formerly used for something else.
>
> I recommend against relying on such nonstandard features at all. Code
> that uses such features quite commonly needs to be fixed later for one
> reason or other, and it is sometimes a lot of work to fix - hugely more
> work than it would have been to just explicitly initialize things
> properly in the first place. I often take such failure to explicitly
> initialize as indicative of failure to think about what the program
> needs, which sometimes is more than just initializing variables to zero.
>
> In the case of allocated arrays, odds are fairly high that it just won't
> work at all.
>
> One thing that does happen when an array is allocated is default
> initialization. But default initialization applies only to derived
> types. It is specified in the type definition.
>
Thanks.
robin
|
| "robin" <rob...@dodo.com.au> wrote in message
| news:4bcdd1a5$0$893$c30e...@exi-reader.telstra.net...
| > "Gib Bogle" <g.b...@auckland.no.spam.ac.nz> wrote in message
| > news:hqjgq0$iad$1...@speranza.aioe.org...
| > | Should one rely on allocated arrays being initialized to zero?
| >
| > Nothing is ever initialized to zero automatically.
| Rubbish.
|
| See for example the compiler option "-zero" on Intel Fortran.
Is that standard Fortran?
glen herrmannsfeldt
>> Nothing is ever initialized to zero automatically.
> Rubbish.
> See for example the compiler option "-zero" on Intel Fortran.
> http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/index.htm
Well, besides that C requires it for static data, in addition
to calloc() for allocating and zeroing.
Also, some systems have faster ways to clear large blocks
of memory than looping over an array of variables. For protection
reasons, multiuser systems require memory to be cleared if it might
still have data from another user. Normally that is with zeros.
Then again, one should learn never to make absolute statements.
-- glen
Gib Bogle
> Then again, one should learn never to make absolute statements.
Never? ;-)
Richard Maine
Colin Watters
"robin" <rob...@dodo.com.au> wrote in message
news:4bce6070$0$895$c30e...@exi-reader.telstra.net...
Where does it say "standard Fortran" in "Nothing is ever initialized to
zero automatically"?
robin
Where does it say that everything is initialized to zero?
Dick Hendrickson
One of my early favorite machines initialized memory with
10HURAHORSES*
when it started a new user job. Struck me as funny at the time.
Dick Hendrickson
Jim Xia
> Allocated arrays are not scalars and not local. The option does not exist on
> all compilers. The fact that it is an option should have been a loud and clear
> warning that this is feature to only be used in duress, such as a
> poorly written
> legacy code and even then it will not be of much help as there the problem
> is often the assumption that variables are saved without having been declared
> as such. That is why some compilers offer to initialize all local variables
> to zero and forcing the save atribute for all variables (see save
> option for Intel).
Actually some compilers allow you to specify particular values to be
initialized for local variables, even allocated variables for other
reasons. This can be used to debug your program to discover un-
initialized variables in your code. In particular, if you can specify
NaN for a floating point, you'll almost guranteed to find out all of
un-initialized floats in your program. For un-initialized SAVEd
variables in Fortran, ELF mandates .bss segments to be filled with
zeros. So I guess there will be Linux programmers with impression
that these variables are always initialized to zeros.
Cheers,
Jim
mecej4
> <-- CUT -->
> One of my early favorite machines initialized memory with
> 10HURAHORSES*
> when it started a new user job. Struck me as funny at the time.
>
> Dick Hendrickson
>
195948557. I thought nothing of it but one day I had set the debugger to
display in hex and was pleasantly surprised.
See http://en.wikipedia.org/wiki/Hexspeak
-- mecej4
Colin Watters
"robin" <rob...@dodo.com.au> wrote in message
news:4bcf29d0$0$894$c30e...@exi-reader.telstra.net...
It doesn't. It shows an example of "something" being initialized to zero,
automatically.
Now answer MY question.
Jim Xia
Yeah, I did encounter many "DEAD BEEF". Recently I start to observe
"bad coffe". I guess it's not listed here, but I'm sure it means
something :-)
Cheers,
Jim
glen herrmannsfeldt
> Yeah, I did encounter many "DEAD BEEF". Recently I start to observe
> "bad coffe". I guess it's not listed here, but I'm sure it means
> something :-)
The first bytes of Java (compiled) class files are X'CAFEBABE'
-- glen
Uno
> Uno <merril...@q.com> wrote:
>
>> What does one need to do to set all of an object's attributes to zero?
>
> That doesn't even make sense. Most attributes aren't numeric at all and
> aren't "settable" during execution. I can only suppose you mean
> something other than "attribute", but I can't guess what it would be.
>
I think I wanted the word "component."
How would I set the real components of the living object to zero at the
gitgo?
implicit none
real :: footage, sqft, calc, supply
integer :: cases
type room
real :: hor
real :: vert
character(len=10) :: name
real :: subtract
end type room
type(room) :: living
sqft = 144
cases = 28
footage = 24
supply = cases * footage
print *, "wood supply is ", supply
living%hor = 42
living%vert = 100
living%subtract = 15
calc = living%hor * living%vert - living%subtract
print *, "calc is ", calc
end program
! gfortran -Wall -Wextra m2.f90 -o out
--
Uno
Uno
Thanks, MM, it was more like 2.9 stuff. Having MR&C on your dashboard
is the only way to be driving people around. You'd be amazed how much a
person can read as someone unloads a household's month worth of recycles.
I don't necessarily know that Gib's question is the same as my own, but
let me talk about my own.
I always thought it was cool to have an array in fortran and write
array = 0
, and I've populated the whole darn thing with zeroes. So I've asked
Richard upthread about how much of this I can get away with.
Let me also ask you the following. Is object orientation in fortran a
timesaver?
--
Uno
Tobias Burnus
> How would I set the real components of the living object to zero at the
> gitgo?
Use a default initializer:
> type room
> real :: hor
append a " = 0.0". Then, you have:
type room
real :: hor = 0.0, vert = 0.0, subtract = 0.0
character(len=10) :: name
end type room
(And of cause, any other constant expression is allowed, e.g.,
"name='default'" or "hor=cos(42.0)")
> type(room) :: living
Tobias
Uno
VielenDank, Tobias, that works great.
$ gfortran -Wall -Wextra m3.f90 -o out
m3.f90:8.29:
character(len=10) :: name = "unnamed romm"
1
Warning: CHARACTER expression at (1) is being truncated (12/10)
That's a nice warning. I suppose I can afford 100 percent more bytes:
$ gfortran -Wall -Wextra m3.f90 -o out
$ ./out
wood supply is 672.00000
calc is 4185.0000
42.000000 100.000000 15.000000 unnamed romm
$ cat m3.f90
implicit none
real :: footage, sqft, calc, supply
integer :: cases
type room
real :: hor = 0.0, vert = 0.0, subtract = 0.0
character(len=20) :: name = "unnamed romm"
end type room
type(room) :: living
sqft = 144
cases = 28
footage = 24
supply = cases * footage
print *, "wood supply is ", supply
living%hor = 42
living%vert = 100
living%subtract = 15
calc = living%hor * living%vert - living%subtract
print *, "calc is ", calc
print *, living
end program
! gfortran -Wall -Wextra m3.f90 -o out
$
Gruss,
--
Uno
Craig Powers
More boringly, Microsoft's stuff does debug initialization to sequences
of 0xcc, 0xdd, and 0xcd (or maybe it's dc) depending on the exact
circumstances.
Uno
! Define the basic tree type
type node
character(max_char) :: name ! name of node
real, pointer :: y(:) ! stored real data
type(node), pointer :: parent ! parent node
type(node), pointer :: sibling ! next sibling node
type(node), pointer :: child ! first child node
end type node
How do I extend this node to incorporate the above and thereafter give
them default values?
Until I understand the type definition better, I was thinking having a
unique integer in the node might be a good thing; otherwise isn't it
! Define the basic tree type
type node
character(20) :: name ! name of node
real, pointer :: hor(:) ! stored real data
real, pointer :: vert(:) ! stored real data
real, pointer :: subtract(:) ! stored real data
type(node), pointer :: parent ! parent node
type(node), pointer :: sibling ! next sibling node
type(node), pointer :: child ! first child node
end type node
?
--
Uno