Prev: calling a c function
Next: Fortran in newly released JASON report
From: Richard Maine on 21 Apr 2010 21:35
e p chandler <epc8(a)juno.com> wrote:

> <analyst41(a)hotmail.com> wrote in message
> news:24f1b2ab-86b6-4518-932b-fd48f901ead4(a)w16g2000vbf.googlegroups.com...
> >I need to keep in memory an array of around 60000 character variables,
> > each element of which can have a max length of 4000 byres. But if you
> > add up the lengths of all the actual data values, it is only 1/8 of
> > 60000*4000.
> >
> > What would be the cleanest way to store this data to take advantage of
> > this fact?

> How about an array each of whose elements is a derived type. One component
> is an integer that specifies the string's length. The second is an
> allocatable array of single characters.

Why the redundancy of the separate component for the string length? The
allocatable already stores the length, so you are just replicating that
by also making the length a separate component.
....
> curr_len = len(trim(in_buff))
> if (curr_len == 0) exit

My nose for potential bugs detects two of them here. This assumes two
things. Both assumptions might be correct, but I tend to think it good
to make such assumptions explicit. Otherwise, you are likely to find
that the user of your code doesn't share your assumptions, which asks
for bugs.

1. It assumes that trailing blanks are insignificant. Maybe they are,
maybe not. Nothing in the problem statement specifcally said they were.
If I were actually writing real code in response to such a problem
statement, I'd ask before just assuming this to be so. And I'd document
the assumption in case things changed in the future (or in case the
person who told me that the blanks were insignificant was wrong.)

2. It assumes that a length of 0 is invalid. Again, nothing specifically
said that. Note that it is perfectly legit in f90 and later to have a
zero-length string. (It wasn't in f77).

Note as an aside, that this uses f2003 features. One could do it in
f90/f95 with pointers to arrays of character*1, though that's not nearly
as nice. I might be tempted to use a long character string as a storage
pool (as in Gordon's reply) instead of the pointer to character array
thing. That does assume that the data item lengths don't change after
their initial assignment; otherwise managing the space in the storage
pool becomes much more bother.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: e p chandler on 21 Apr 2010 21:37

"Jim Xia" <jimxia(a)hotmail.com> wrote in message

> module my_mod
> implicit none
>
> type node
> integer :: len
> character, allocatable :: char(:)
> end type
> end module my_mod
>

How about this

type string
character(:), allocatable :: str
end type

You don't need the len variable. len(node%str) will be that value.

---> len() returns a value of 1. Do you mean size()?


From: robert.corbett on 21 Apr 2010 21:47
On Apr 21, 3:22 pm, "analys...(a)hotmail.com" <analys...(a)hotmail.com>
wrote:
> I need to keep in memory an array of around 60000 character variables,
> each element of which can have a max length of 4000 byres. But if you
> add up the lengths of all the actual data values, it is only 1/8 of
> 60000*4000.
>
> What would be the cleanest way to store this data to take advantage of
> this fact?

How is the array to be used? What operations will be
performed on it?

Robert Corbett
From: Jim Xia on 21 Apr 2010 21:49
On Apr 21, 9:37 pm, "e p chandler" <e...(a)juno.com> wrote:
> "Jim Xia" <jim...(a)hotmail.com> wrote in message
> > module my_mod
> > implicit none
>
> > type node
> > integer :: len
> > character, allocatable :: char(:)
> > end type
> > end module my_mod
>
> How about this
>
> type string
>    character(:), allocatable :: str
> end type
>
> You don't need the len variable.  len(node%str) will be that value.
>
> ---> len() returns a value of 1. Do you mean size()?


Sorry, I meant len(string%str). I renamed the type name and component
name after I typed in the sentence -- forgot to correct them.

character(:), allocatable :: str is a scalar of character with
deferred length. You can automatically allocate this string by
assignment -- see my full example.


Cheers,

Jim
From: Richard Maine on 21 Apr 2010 21:51
e p chandler <epc8(a)juno.com> wrote:

> "Jim Xia" <jimxia(a)hotmail.com> wrote in message
>
> > module my_mod
> > implicit none
> >
> > type node
> > integer :: len
> > character, allocatable :: char(:)
> > end type
> > end module my_mod
> >
>
> How about this
>
> type string
> character(:), allocatable :: str
> end type
>
> You don't need the len variable. len(node%str) will be that value.
>
> ---> len() returns a value of 1. Do you mean size()?

No, he means len. If len returns other than the correct value, report
the bug to your vendor. Allocatable character length being one of the
f2003 features last on the implementation list, it could well be that
your vendor has such a bug... but it would be a bug.

Size is quite irrelevant. Your compiler shouldn't even allow
size(node%str) in Jim's example, as it isn't an array. If your compiler
allows that, there's another bug to report (and a more surprising one).

Your example uses an array of characters (I missed that at first), but
Jim's uses a character string instead. They are different.

Note also the handy way that Jim's example (in his subsequent followup)
nicely uses the f2003 allocate-on-assignment feature. I think it nicely
illustrates the cleanliness you can get from using allocatable character
length and that feature.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: calling a c function
Next: Fortran in newly released JASON report