| View previous topic :: View next topic |
| Author |
Message |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
 Posted: Sun Dec 06, 2015 12:16 am Post subject: |
 |
|
John,
I am a bit with you on this.
I find derived types are very useful for assembling data. It groups the data and makes it�s name more meaningful.
However, Fortran has become far more complex. Why do we need polymorphic types and all the new code structures in F03 and F08?
All I see of this is more and more complex data structures and code.
The computer scientist�s justification for this complexity was �object orientated coding� created better coding structures that had fewer bugs, but the complexity has continued to grow.
I always recommend the �keep it simple� approach which has served me well.
I see examples of these new approaches on other forums and I do wonder what sort of problems the modern Fortran solves. I often think all they produce is a useless complex mess with no significant outcome. Often there appear to be a simple alternative data structure that could achieve the same result.
I am not aware of where this new complexity is being used. The achievements of Fortran since the 60�s in engineering have been huge, without these complex additions, while most recent computing advances appear to be outside the standard, eg vector and parallel processing.
I am sure many may disagree with me, but where are their results.
John |
|
| Back to top |
|
 |
IanLambley
Joined: 17 Dec 2006
Posts: 506
Location: Sunderland
|
| Posted: Mon Dec 07, 2015 1:56 pm Post subject: |
|
|
Being an old fashioned Fortran programmer, I find that the use of derived types is never in my mind at the beginning of a program development. But where I have used them, they have their advantages in copying data, assigning and passing data as an argument. Instead of referring to each individual element in a series of arrays in say a swap type sort, you only have to do the swap with a single short name and array index. It is worth sticking with the idea and it will gradually become more helpful in new programs.
Ian |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1257
Location: Morrison, CO, USA
|
| Posted: Mon Dec 07, 2015 7:19 pm Post subject: |
|
|
Ian, I'm with you!
I'm finding as I update old code or add new code that the derived types can make the handling of data almost trivial. Also, the ability to initialize each data item in the type individually to what it needs to be when it is created has allowed a great freedom.
While it is not the be-all and end-all, it is useful, just as keeping data in separate named items is sometimes most efficient, either from the coding or the maintenance of the code. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Tue Dec 08, 2015 12:26 am Post subject: |
|
|
I use derived types for data structures. One approach I have found useful is to define parameters for initialisation, such as "zero" or "one". This simplifies initiating all the different types of elements of the type. eg: | Code: | TYPE COMMODITY_RECORD
integer*4 terminal
integer*4 brand_id
real*4 tonnage
real*4 fines_fr
integer*4 fines_id
integer*4 sustained_rate
integer*4 gross_rate
integer*4 no_direct
character brand_name*10
END TYPE COMMODITY_RECORD
!
type (Commodity_Record), parameter :: &
Commodity_zero = Commodity_record (0, 0, 0., 0., 0, 0, 0, 0, ' ')
!
type (Commodity_Record) Commodity(m$brand)
...
do i = 1,m$brand
Commodity(i) = Commodity_zero
end do
! or
Commodity = Commodity_zero
|
|
|
| Back to top |
|
|
IanLambley
Joined: 17 Dec 2006
Posts: 506
Location: Sunderland
|
| Posted: Tue Dec 08, 2015 1:28 pm Post subject: |
|
|
Probably a good idea to stick the keyword "SEQUENCE" in the definition.
Is there an intrinsic function to find the length in bytes of a derived type?
Ian
"The compiler is free to store the constituents of a derived type how it chooses. To force the derived type to be stored contiguously, use the sequence keyword." |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Tue Dec 08, 2015 2:23 pm Post subject: |
|
|
Ian,
Where did you get the quote from? | Quote: | | The compiler is free to store the constituents of a derived type how it chooses. To force the derived type to be stored contiguously, use the sequence keyword. |
If you transfer a derived type as a subroutine argument, what assumptions can you make about how it is transferred. Surely, with limited assumptions there will be less efficiency in the transfer. I presume that the derived type definition should be in a use module. I tend to declare all my derived types in a module and not use them as routine arguments.
Determining the length of arrays or derived type is an interesting problem, especially if you want the length in bytes.
SIZE will give the length of an intrinsic type array as elements of the array (section), but not derived types.
There is a F2008 intrinsic STORAGE_SIZE which returns the bit length of an array of any type. Not sure if this includes both intrinsic and derived types. It would be a useful addition to FTN95. Storage_size reports the memory size, so if it includes derived types, it also accounts for alignment spacing of derived type elements.
Ifort provides a function SIZEOF which returns the byte size of an array of any type. Again, not sure if this includes both intrinsic and derived types. I think this would be a very useful addition to FTN95.
You can approach this by using the LOC function, which also I could not find listed in the Fortran standards I have.
It is a shame that the byte size of any nameable group can not be sized in bytes. Something a Fortran user wants!
Lately I have been lobbying Silverfrost to include more functions in SALFLIBC.DLL. I would like more information functions, such as SIZEOF or Compiler_Version or DOT_PRODUCT_SSE etc, which do not require new coding structures that are in F03 or F08.
John |
|
| Back to top |
|
|
IanLambley
Joined: 17 Dec 2006
Posts: 506
Location: Sunderland
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Wed Dec 09, 2015 11:12 pm Post subject: |
|
|
I don't know if this is the right thread but someone was asking how to get the size of a user defined type. Here is one way...
| Code: | type atype
integer k
double precision x
end type
type(atype)::a
integer sizeof
inquire(iolength=sizeof) a
print*, sizeof
end
|
|
|
| Back to top |
|
|
IanLambley
Joined: 17 Dec 2006
Posts: 506
Location: Sunderland
|
| Posted: Thu Dec 10, 2015 8:36 am Post subject: |
|
|
Paul,
Thanks for that.
Ian |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
