For Programmers: Free Programming Magazines  


Home > Archive > Fortran > November 2005 > default initialisation









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author default initialisation
Joost

2005-11-23, 7:57 am

Hi,

is there any easy/clean way to reset the value of a derived type to
whatever it was when it is created? This seems particularly useful
together with default initialisation. What I want can be done like in
this oversimplified example:

MODULE M1
TYPE T1
INTEGER :: i=7
END TYPE T1
CONTAINS
SUBROUTINE reset(d)
TYPE(T1), INTENT(OUT) :: d
END SUBROUTINE reset
END MODULE M1

USE M1
TYPE(T1) :: d
! do something with d
d%i=0
! restore default
CALL reset(d)
END

but it seems rather ugly to have to write the silly reset call for each
derived type (at that point it makes much more sense to write an 'init'
routine for each type).

Two things that seemed 'logical' to me seem not allowed:

d=T1()

or

TYPE(T1), PARAMETER :: t1_default
d=t1_default

Thanks,

Joost

Michael Metcalf

2005-11-23, 7:57 am


"Joost" <jv244@cam.ac.uk> wrote in message
news:1132748897.042355.292240@g43g2000cwa.googlegroups.com...
> Hi,
>
> is there any easy/clean way to reset the value of a derived type to
> whatever it was when it is created?


The standard says that variables become undefined when they go out of scope.
If I rewrite your code as

MODULE M1
TYPE T1
INTEGER :: i=7
END TYPE T1
END MODULE M1

call s
call s
end program

subroutine s
USE M1
TYPE(T1) :: d
print *, d%i
d%i=0
print *, d%i
END subroutine s

it prints

7
0
7
0

Note that M1 is not used in the main program (see also "Fortran 95/2003
Explained", Section 7.9).

Regards,

Mike Metcalf


Joost

2005-11-23, 7:57 am


that doesn't really solve my problem. I must be able to 'actively'
reset the value to whatever the default is. In particular, I have an
array of derived types where I can 'merge' two elements, yielding a
meaningful result for one of the two elements, but the second element
needs to be reset to the default as part of this merge operation.

Joost

Helge Avlesen

2005-11-23, 7:57 am

"Joost" <jv244@cam.ac.uk> writes:

> d=T1()


this is pretty close, and should be allowed:

[avle@tindved avle]$ cat > der.f90
type t1
integer :: i=0
end type
type(t1) d

d=t1(2)
print *,d
end
[avle@tindved avle]$ g95 der.f90 && ./a.out
2

--
Helge
Joost

2005-11-23, 7:57 am

This is allowed, but isn't really what I want. Not only can the type be
very complex (so that providing values in the constructor is nearly
hopeless, especially if this derived type contains other derived types
with default initialisation) but also you need to know what the
defaults are at that point in the code, which is what I want to avoid.

Joost

Jugoslav Dujic

2005-11-23, 7:00 pm

Joost wrote:
| Hi,
|
| is there any easy/clean way to reset the value of a derived type to
| whatever it was when it is created? This seems particularly useful
| together with default initialisation. What I want can be done like in
| this oversimplified example:
|

| Two things that seemed 'logical' to me seem not allowed:
|
| TYPE(T1), PARAMETER :: t1_default
| d=t1_default

Why is this not allowed? AFAIK it is.

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Dan Nagle

2005-11-23, 7:00 pm

Hello,

Jugoslav Dujic wrote:
> Joost wrote:
> | Hi,
> |
> | is there any easy/clean way to reset the value of a derived type to
> | whatever it was when it is created? This seems particularly useful
> | together with default initialisation. What I want can be done like in
> | this oversimplified example:
> |
>
> | Two things that seemed 'logical' to me seem not allowed:
> |
> | TYPE(T1), PARAMETER :: t1_default
> | d=t1_default
>
> Why is this not allowed? AFAIK it is.


A parameter is a named constant, it is known
during compilation. Therefore is must have a value
on the declaration, rather than later, in the executable code.

Specifically, one named constant may provide a value
for another.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
Rich Townsend

2005-11-23, 7:00 pm

Dan Nagle wrote:
> Hello,
>
> Jugoslav Dujic wrote:
>
>
>
> A parameter is a named constant, it is known
> during compilation. Therefore is must have a value
> on the declaration, rather than later, in the executable code.
>
> Specifically, one named constant may provide a value
> for another.
>


Well, how about

TYPE(T1), PARAMETER :: t1_default = T1()

ie, use the default initializer. Would that work?

cheers,

Rich
Jugoslav Dujic

2005-11-23, 7:00 pm

Dan Nagle wrote:
| Hello,
|
| Jugoslav Dujic wrote:
|| Joost wrote:
||| Hi,
|||
||| is there any easy/clean way to reset the value of a derived type to
||| whatever it was when it is created? This seems particularly useful
||| together with default initialisation. What I want can be done like in
||| this oversimplified example:
|||
||
||| Two things that seemed 'logical' to me seem not allowed:
|||
||| TYPE(T1), PARAMETER :: t1_default
||| d=t1_default
||
|| Why is this not allowed? AFAIK it is.
|
| A parameter is a named constant, it is known
| during compilation. Therefore is must have a value
| on the declaration, rather than later, in the executable code.

Yes, when I think about it...

However, it should fulfill Joost's requirement without
PARAMETER attribute? Not as typesafe but...

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Joost

2005-11-23, 7:00 pm

also this is not allowed, but in my eyes starts making lots of sense
and would maybe be a good addition for a next Fortran standard. I.e.
use T1() as the derived type with each component having its default
initialisation. That seems to make a lot of sense, not only in
declarations but also in the executable part of the code. Maybe one has
to think carefully on how to phrase things in the case where not all
components are defined since it would still be nice if one could assign
T1() to a variable in that case.

Joost

Dan Nagle

2005-11-23, 7:00 pm

Hello,

Jugoslav Dujic wrote:

<snip>

> However, it should fulfill Joost's requirement without
> PARAMETER attribute? Not as typesafe but...


A named constant and a variable may appear similar, but they
are very different.

A variable implies storage, a named constant does not.

For example,

integer, parameter :: one = 1

need not be stored anywhere. Appearances of

i = i + one

might imply nothing more than the compiler emitting
its "increment register" instruction, rather than
its "add two registers" instruction.

OTOH,

integer, save :: i = 0

implies storage, most likely in memory, while

integer :: loop_index

also implies storage, quite possibly nowhere beyond
a register.

HTH

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
Helge Avlesen

2005-11-23, 7:00 pm

Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:

> Dan Nagle wrote:
>
> Well, how about
>
> TYPE(T1), PARAMETER :: t1_default = T1()
>
> ie, use the default initializer. Would that work?


is there such a thing as a def. initializer in Fortran? I think
something like this will be necessary:

type t1
integer :: i
end type t1
type(t1) a
type(t1), parameter :: default_a = t1(0)
....
a = default_a
....

--
Helge
Joost

2005-11-23, 7:00 pm

> However, it should fulfill Joost's requirement without
> PARAMETER attribute? Not as typesafe but...


yes, it would, but is indeed not so elegant because it could be changed
accidentally.


JOost

Rich Townsend

2005-11-23, 7:00 pm

Joost wrote:
> also this is not allowed, but in my eyes starts making lots of sense
> and would maybe be a good addition for a next Fortran standard. I.e.
> use T1() as the derived type with each component having its default
> initialisation. That seems to make a lot of sense, not only in
> declarations but also in the executable part of the code. Maybe one has
> to think carefully on how to phrase things in the case where not all
> components are defined since it would still be nice if one could assign
> T1() to a variable in that case.
>
> Joost
>


Well, the feature could be defined in a way that T1() is only valid as the
default initializer *if* all components of type(T1) have default values. This is
something that can be checked at compile time.

Any thoughts from the wider audience as to this going in to F2008?

cheers,

Rich
Colin Watters

2005-11-23, 7:00 pm

how about :

MODULE M1
TYPE T1
INTEGER :: i=7
END TYPE T1
END MODULE M1

USE M1
TYPE(T1) :: d, e
! do something with d
d%i=0
! restore default
d = e
END

If your'e worried that e might get altered, you could:

MODULE M1
TYPE T1
INTEGER :: i=7
END TYPE T1
END MODULE M1

USE M1
TYPE(T1) :: d
type(t1), pointer :: e
! do something with d
d%i=0
! restore default
allocate(e)
d = e
deallocate(e)
END

--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
"Joost" <jv244@cam.ac.uk> wrote in message
news:1132748897.042355.292240@g43g2000cwa.googlegroups.com...
> Hi,
>
> is there any easy/clean way to reset the value of a derived type to
> whatever it was when it is created? This seems particularly useful
> together with default initialisation. What I want can be done like in
> this oversimplified example:
>
> MODULE M1
> TYPE T1
> INTEGER :: i=7
> END TYPE T1
> CONTAINS
> SUBROUTINE reset(d)
> TYPE(T1), INTENT(OUT) :: d
> END SUBROUTINE reset
> END MODULE M1
>
> USE M1
> TYPE(T1) :: d
> ! do something with d
> d%i=0
> ! restore default
> CALL reset(d)
> END
>
> but it seems rather ugly to have to write the silly reset call for each
> derived type (at that point it makes much more sense to write an 'init'
> routine for each type).
>
> Two things that seemed 'logical' to me seem not allowed:
>
> d=T1()
>
> or
>
> TYPE(T1), PARAMETER :: t1_default
> d=t1_default
>
> Thanks,
>
> Joost
>



Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com