Refactor and extend field_list

[timofeymukha]

Here, I start implementing a convention for helper types.

• _list_t types have its component called items
• _ptr_t types have its component called ptr

I add a lot of convenience subroutines for the field_list_t, so that one can avoid expressions like this%fields%items(i)%ptr%x_d etc as much as possible. I would say quite a lot of code looks more elegant now. I will add a routine to return x for an item as well, I just need to look up how to return allocatable arrays in a good way (maybe it is trivial).

The next step will be to add a similar list type for vector_ptr_t and array_ptr_t.

[timofeymukha]

Quite happy now. A little bit scared if the %x and %x_d routines in field_list_t are correctly written though.

[timofeymukha]

I have now added wrappers for all the components of field_t and also a wrapper for field_t%size, which is called item_size, because size is used to get the size of the field list itself. I also use the x(i) wrapper everywhere now. set has been renamed to assign as per @timfelle suggestion.

The only thing "unclean" left in the codebase are the assignments in fld_file. Otherwise, we could make items private. @timfelle I think you had an idea for what to do with them, or? Could you maybe try to show the way with one of the assignment there?

[timofeymukha]

Interesting, it seems like some compilers won't accept passing an array pointer to a subroutine which takes an array as an in/out argument. Am I interpreting this correctly, @njansson ? Then I guess the usefulness of the x() wrapper is quite limited.

[njansson]

Interesting, it seems like some compilers won't accept passing an array pointer to a subroutine which takes an array as an in/out argument. Am I interpreting this correctly, @njansson ? Then I guess the usefulness of the x() wrapper is quite limited.

True, the standard would (rightfully so) reject that ;) Ok then I guess we drop x() for now

[timofeymukha]

Interesting, it seems like some compilers won't accept passing an array pointer to a subroutine which takes an array as an in/out argument. Am I interpreting this correctly, @njansson ? Then I guess the usefulness of the x() wrapper is quite limited.

True, the standard would (rightfully so) reject that ;) Ok then I guess we drop x() for now

Yes.. And with that unfrotunately also the dream of private items.

[timofeymukha]

Interesting, it seems like some compilers won't accept passing an array pointer to a subroutine which takes an array as an in/out argument. Am I interpreting this correctly, @njansson ? Then I guess the usefulness of the x() wrapper is quite limited.

True, the standard would (rightfully so) reject that ;) Ok then I guess we drop x() for now

Yes.. And with that unfrotunately also the dream of private items.

Could we atleast add the x and x_d pointers to field_ptr_t so we don't have to do list(i)%ptr%x but can do list(i)%x?

x_d we still have in the list since that does not seem to cause trouble, as we copy a c_ptr. Regarding x I honestly have no idea :-). I guess since it is a pointer it will have the same issue? Or if we store the %x pointer as a component, it would be different compared to returning a pointer from a function?

[timofeymukha]

How do we feel about merging this in now that we have the 0.8 branched out?