# Should we use pointers to make user friendly interfaces?

**URL:** <https://fortran-lang.discourse.group/t/should-we-use-pointers-to-make-user-friendly-interfaces/7342>\
**Category:** Uncategorized\
**Created:** [February 5, 2024, 2:08pm UTC](https://fortran-lang.discourse.group/t/should-we-use-pointers-to-make-user-friendly-interfaces/7342 "2024-02-05T14:08:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![aerosayan](https://avatars.discourse-cdn.com/v4/letter/a/8c91f0/32.png) [@aerosayan](https://fortran-lang.discourse.group/u/aerosayan)\
**Post date:** [February 5, 2024, 2:08pm UTC](https://fortran-lang.discourse.group/t/should-we-use-pointers-to-make-user-friendly-interfaces/7342/1 "2024-02-05T14:08:50Z")

</div>

Hello everyone,

I’m trying to write a user friendly derived type, so I can access data more easily.

For example,

I have cell data of at triangular cell, and a quadrilateral cell, of form …

`cells = [1, 2, 3, 40, 50, 60, 70]` where each integer is a node index.

and it can be accessed with a “index map” of form …

`imcells = [1, 4, 8]` which says, first cell starts at index 1, and second cell starts at index 4. The difference between 4 and 1 says, first cell contains 3 nodes, and difference between 8 and 4 says, second cell contains 4 nodes.

This is a fairly standard data format used for polygonal grids, and is also used in libraries like METIS. It’s also very similar to CSR (Compressed Sparse Row) format used in Linear Algebra libraries.

To access the cell nodes, I need to use the index map to cells i.e `imcells`.

Understandably that is complex, and not user-friendly for writing mathematical equations.

So, I tried to create a type `vIndexMapIkA` that uses pointers to access `cell`, and `imcell`, and make it possible for me to acess the data normally. On the right side of the attached picture, we have methods for accessing data …

- with read-only access as `object%at(ii, kk)` that returns an integer value and
- with read-write access as `object%in(ii, kk)` that returns a pointer to the integer data, so we can modify it.

My questions are,

- Is this safe?
  - I have seen that with pointers I can even modify data that was `intent(in)`, but luckily, I can prevent accidental writes by being careful, and using the `at(ii, kk)` method, since it only provides read-only access.

- Is this going to be bad for performance?
  - The code that I’m showing is not performance critical code, but it would be nice, if it wasn’t bad for performance.
  - I only use this locally inside functions, so any good compiler shouldn’t have difficulty identifying aliasing at compile time.

- Is there some other better way?
  - I need the code to be stable for decades, so I would like to use any other safe alternative, that’s similarly user-friendly.

Thanks.

Pictures:

- On Left:
  - The highlighted sections show how `at()` and `in()` methods are being used.
  - _Kindly pay no attention to other things on the left. They’re not relevant to the question_

- On Right:
  - The code for `vIndexMapIkA` that shows how I’m trying to use pointers to create a more user-friendly interface.
  - _Kindly scrutinize it for safety and performance._

 ![codex](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/9/998db4a8f6235e645ea6fcbfde8da5bbb2aa8a1a.png)

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [February 5, 2024, 4:55pm UTC](https://fortran-lang.discourse.group/t/should-we-use-pointers-to-make-user-friendly-interfaces/7342/2 "2024-02-05T16:55:30Z")

</div>

Concerning your `set` subroutine, I would recommend using the `pointer` attribute for the input arguments, in line with the discussion in this thread: [Why/When is the `target` attribute part of the characterisics of a procedure - #3 by aradi](https://fortran-lang.discourse.group/t/why-when-is-the-target-attribute-part-of-the-characterisics-of-a-procedure/4826/3)
