-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Routines to handle (allocatable) character arrays #315
Comments
Can't one just recover a pointer to the first element of string array (assuming contiguous memory layout)? Then all of the current functions for character scalars can be reused. The
|
Is there any interest in having a helper function to convert between a literal character set like For character variables one can get away with This proposal is partially motivated by the newly proposed pure function str_to_arr_char(string) result(array)
character(len=*), intent(in) :: string
character(len=1), dimension(len_trim(string)) :: array
end function
pure function str_to_arr_chunk(string,len) result(array)
character(len=*), intent(in) :: string
integer, intent(in) :: len
integer, parameter :: sz = len_trim(string)/len + merge(0,1,mod(len_trim(string),len) == 0)
character(len=len), dimension(sz) :: array
end function A second version allows a string to be broken into an array of fixed-length chunks. Both versions could have an optional |
Is it possible to merge the two? I am not sure if present() can be used to
calculate the result array's size, but otherwise you could implement
str_arr_char by calling str_arr_chunk. Saves a specific function.
Op di 30 mrt. 2021 om 11:13 schreef Ivan Pribec ***@***.***>:
… Is there any interest in having a helper function to convert between a
literal character set like 'abc' and a set of characters ['a', 'b', 'c']?
For character variables one can get away with
[(set(i:i),i=1,len_trim(set))], which is annoying since a new integer
variable needs to be introduced (at least Fortran 202X will introduce the
possibility of declaration in implied do loops).
This proposal is partially motivated by the newly proposed chomp API (see
#343 <#343>), but it would
likely be useful in other usage cases too.
pure function str_to_arr_char(string) result(array)
character(len=*), intent(in) :: string
character(len=1), dimension(len_trim(string)) :: arrayend functionpure function str_to_arr_chunk(string,len) result(array)
character(len=*), intent(in) :: string
integer, intent(in) :: len
integer, parameter :: sz = len_trim(string)/len + merge(0,1,mod(len_trim(string),len) == 0)
character(len=len), dimension(sz) :: arrayend function
A second version allows a string to be broken into an array of
fixed-length chunks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#315 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN6YRZ2DOGP7HBFKWR2KBDTGGI2TANCNFSM4XNSBUDA>
.
|
You could always pure function string_to_set(string) result(set)
character(len=*), intent(in) :: string
character(len=1) :: set(len(string))
set = transfer(string, ' ', size=len(string))
end function string_to_set
pure function set_to_string(set) result(string)
character(len=1), intent(in) :: set(:)
character(len=size(set)) :: string
string = transfer(set, string)
end function set_to_string |
I briefly recall having some problems when using
but would need to double check this. |
Note that GCC 8 won't be able to evaluate more complex expressions in the declaration, |
I guess transfer is the better option for inlining. But putting it into a clear function helps clarify meaning. If I met a statement like |
On more thought, I would skip any optional trimming and simply follow @awvwgk's version. Users can always do Addendum: since I am afraid the word |
I would prefer to see this delegated to a function called Makes we wonder if the opposite direction should also be called |
Fine with me, let's schedule this feature after we arrive at |
The changes look good to me as well. |
The
|
What is the preferred approach to convert an array of The opposite direction I believe is solved by the elemental type(string_type), allocatable :: st_names(:)
character(len=32), allocatable :: names(:)
allocate(st_names(5))
st_names(1) = string_type("Adam")
..
st_names(5) = string_type("Zion")
names = [(char(st_names(i)), i = 1, size(st_names))]
! helper subprogram
call string_type_to_character(st_names,names,len=maxval(len(st_names))) subroutine string_type_to_character(sa,ca,len)
type(string_type), intent(in) :: sa(:)
character(len=:), allocatable, intent(out) :: ca(:)
integer, intent(in) :: len
allocate(character(len=len) :: ca(size(sa)))
do i = 1, size(sa)
ca(i) = char(sa(i))
end do
end subroutine |
Another representation of strings rather than the fixed length character or deferred length character variable could be (allocatable) character array. Converting between deferred length character variables and allocatable character arrays is usually possible with the intrinsic
transfer
function. Especially for C compatible routines that do not yet use the ISO-Fortran binding header on the C side this is a frequently used functionality.Should stdlib provide helper functions for operations on character arrays? Most of those will be automatic due to
elemental
functions instdlib_ascii
at some point, but (safe) conversion routines between allocatable character arrays and deferred length characters might be a useful addition (module namespace?).The text was updated successfully, but these errors were encountered: