Prev: Matlab mexing with gfortran -- String handling.
Next: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
From: Uno on 22 Apr 2010 03:16
m_b_metcalf wrote:
> On Apr 20, 8:26 am, Uno <merrilljen...(a)q.com> wrote:
>> I brushed a thick layer of dust off MR&C and was largely unsuccessful in
>> a similar endeavor.
>>
> Then might I draw your attention to Section 3.3, 'Defined and
> undefined variables'.

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
From: Tobias Burnus on 22 Apr 2010 03:32
On 04/22/2010 08:46 AM, Uno wrote:
> 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
From: Uno on 22 Apr 2010 05:07
Tobias Burnus wrote:
> On 04/22/2010 08:46 AM, Uno wrote:
>> 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)")

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
From: robin on 21 Apr 2010 12:37
"Colin Watters" <boss(a)qomputing.com> wrote in message news:hqm6l4$2kd$1(a)news.eternal-september.org...
|
| "robin" <robin51(a)dodo.com.au> wrote in message
| news:4bce6070$0$895$c30e37c6(a)exi-reader.telstra.net...
| > "Colin Watters" <boss(a)qomputing.com> wrote in message
| > news:hqkvmd$t8d$1(a)news.eternal-september.org...
| > |
| > | "robin" <robin51(a)dodo.com.au> wrote in message
| > | news:4bcdd1a5$0$893$c30e37c6(a)exi-reader.telstra.net...
| > | > "Gib Bogle" <g.bogle(a)auckland.no.spam.ac.nz> wrote in message
| > | > news:hqjgq0$iad$1(a)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?
|
| Where does it say "standard Fortran" in "Nothing is ever initialized to
| zero automatically"?

Where does it say that everything is initialized to zero?


From: Jim Xia on 21 Apr 2010 13:49

> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Matlab mexing with gfortran -- String handling.
Next: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard