… note Fortran does NOT provide direct interoperability with C++ classes and Fortran code can have no direct understanding of object instances created in C++. Rather Fortran provides interoperability with the C companion processor which you will know is similar to what C++ provides with extern “C” entities …
So with “bigger, complex C++ libraries” , anything that works with C++ <–> C <–> Fortran model is ok i.e., with C as the middle layer.
I use stdc++ containers inside fortran, e.g. vector, map, list etc. Every fortran code I wrote could get near/to the performance of those containers, but was usually never faster. It would be a game changer for fortran if the fortran std lib development could replicate/improve/outperform stdc++. This is because it is exactly the absence of the house keeping stuff stdc++ provides which makes life for fortrunners sooo tedious. This obviously feeds into the counter-intuitive rise of phyton
Is it the methods of these containers that are useful to you? E.g. being able to dynamically grow a list using the push_back, or having the algorithms from STL to operate on the containers (counting, searching, sorting, accumulating…).
You can propose an API to the stdlib effort. The actual implementation can be done in Fortran or C++. Granted, we can’t replicate the full power of templated containers (at least not without some heavy preprocessing solutions), but at least for intrinsic types (integer, real, character), I see no issues apart from reaching an agreement.
I doubt a Fortran implementation could be much or any faster at all. The industry has invested heavily in improving the speed of C++ executables.
Currently I use the methods. The biggest difference to native fortran I found was the memory usage. I had to put all tricks in to get a native fortran map as parsimonious as the STL map.
I found the algorithms sometimes slow.
But the main problem with STL is that it is, to my knowledge, not threaded. There are operations on vector, list etc. which can be parallelised. Further, the access to the actual memory of, say a vector, is a bit cumbersome. And having easy access to the actual memory for slice operations is a must in hpc. Therefore I think there is still some room for improvement, especially with regard to hpc.
SWIG is a quite powerful tool, I have explored it to generate interfaces from Fortran to Python in the past and it works really well. Missing build system support in meson forced me to use CFFI instead, but CMake seems to have a decent support for building interfaces with SWIG and handling the resulting artifacts for installation.
The one thing that is really cool with both SWIG and CFFI that you only have to go once through the trouble of setting them up, maintenance effort has been almost non-existent so far. Would be interesting to see if the same holds true for the C++ to Fortran bindings, but I usually interface in the other direction.
kar.may> I use stdc++ containers inside fortran, e.g. vector, map, list etc. Every fortran code I wrote could get near/to the performance of those containers, but was usually never faster. It would be a game changer for fortran if the fortran std lib development could replicate/improve/outperform stdc++. This is because it is exactly the absence of the house keeping stuff stdc++ provides which makes life for fortrunners sooo tedious.
Out of curiosity, is your library (that wraps stdc++ for Fortran use) accessible on Github etc, or currently for internal use only?
Ivan> I doubt a Fortran implementation could be much or any faster at all. The industry has invested heavily in improving the speed of C++ executables.
Pretty much ago, I once asked some question about a possible “string” type on comp.lang fortran, and the answer was essentially: “Use iso_varying_string”. This is equal to using a user-defined (derived) type that contains an allocatable character string, so I tested its performance with some minimal test problems. However, IIRC, the performance was not good as compared to, e.g. std::string in C++. The speed of other languages vary, but even those with GC were still faster. The unfavorable performance of character strings in Fortran may be partly for various reasons (my codes, the compiler used, overhead of intrinsic character strings, etc etc) and may be not very important for numerical calculations (e.g., “string is used only for file names”). But I guess similar performance issues can happen for some other things (particularly collection types) unless they are provided natively by compilers.