Moved t8_forest_element_from_ref_coords implementation into cxx file.

[jmark]

Describe your changes here:

Title says it all. Only some compiler versions make inline [...] routines in header files also visible as symbols in shared libraries which application then can use in their code. Otherwise the routine is statically inlined in the t8code library and cannot be called by external applications.

All these boxes must be checked by the reviewers before merging the pull request:

As a reviewer please read through all the code lines and make sure that the code is fully understood, bug free, well-documented and well-structured.

General

• The reviewer executed the new code features at least once and checked the results manually

• The code follows the t8code coding guidelines

• New source/header files are properly added to the Makefiles

• The code is well documented

• All function declarations, structs/classes and their members have a proper doxygen documentation

• All new algorithms and data structures are sufficiently optimal in terms of memory and runtime (If this should be merged, but there is still potential for optimization, create a new issue)

Tests

• The code is covered in an existing or new test case using Google Test

Github action

• The code compiles without warning in debugging and release mode, with and without MPI (this should be executed automatically in a github action)

• All tests pass (in various configurations, this should be executed automatically in a github action)

  If the Pull request introduces code that is not covered by the github action (for example coupling with a new library):

  • Should this use case be added to the github action?
  • If not, does the specific use case compile and all tests pass (check manually)

Scripts and Wiki

• If a new directory with source-files is added, it must be covered by the script/find_all_source_files.scp to check the indentation of these files.
• If this PR introduces a new feature, it must be covered in an example/tutorial and a Wiki article.

Licence

• The author added a BSD statement to doc/ (or already has one)

[sandro-elsweijer]

@jmark With which compiler do you have the problem? Does it maybe work with the cpp17 branch?
inline is by far not a new feature and I am worried, that we will never program in a modern way, if we block "new" concepts because of ancient compilers

[jmark]

@jmark With which compiler do you have the problem? Does it maybe work with the cpp17 branch? inline is by far not a new feature and I am worried, that we will never program in a modern way, if we block "new" concepts because of ancient compilers

@sandro-elsweijer I totally get your point and sympathize with your view.

On my workstation I compiled t8code with g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 and even tried -std=c++17. It does not create a symbol for t8_forest_element_from_ref_coords in the shared library libt8.so. This compiler version series is not that old. It started from 2019 and last revision was released in 2022: https://gcc.gnu.org/gcc-9/

g++ (Spack GCC) 12.1.0 on the other hand creates a symbol entry in libt8.so.

This raises a general question on how we want to handle compatibility to many different kinds of compilers and platforms.

[sandro-elsweijer]

@jmark With which compiler do you have the problem? Does it maybe work with the cpp17 branch? inline is by far not a new feature and I am worried, that we will never program in a modern way, if we block "new" concepts because of ancient compilers

@sandro-elsweijer I totally get your point and sympathize with your view.

On my workstation I compiled t8code with g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 and even tried -std=c++17. It does not create a symbol for t8_forest_element_from_ref_coords in the shared library libt8.so. This compiler version series is not that old. It started from 2019 and last revision was released in 2022: https://gcc.gnu.org/gcc-9/

g++ (Spack GCC) 12.1.0 on the other hand creates a symbol entry in libt8.so.

This raises a general question on how we want to handle compatibility to many different kinds of compilers and platforms.

Does this her maybe help? https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html

[jmark]

Does this her maybe help? https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html

Not sure, what you are aiming at.