Hi. I discovered that we can mix Fortran, C and C++ in a single program. In this particular case [1] I can add “stdc++” to the link section of fpm.toml then gfortran compiles/link everything.
I wonder if this “trick” works with bigger, complex C++ libraries. Just curious …
[1] datetime-fortran/strptime.cpp at master · wavebitscientific/datetime-fortran · GitHub
@une ,
You may want to review this post from several years ago: community.intel.com/t5/Intel-Fortran-Compiler/Calling-C-cpp-objects-from-a-Fortran-subroutine/m-p/1110557#M129102
As I write in there,
… 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.
@FortranFan is spot on. However, you might want to have a look at Shroud (very interesting and promising but I had zero time to dedicate to fiddle a little bit with it 
)
“Shroud” seems interesting, but it may be better to not play with it when busy…
Exactly, been there, done that… multiple times 
@une, we want to support this in fpm, and it should eventually work even without having to specify any such stdc++ flags. I just created an issue for this: Support for C and C++ source files and linking everything together · Issue #353 · fortran-lang/fpm · GitHub
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.
Recently, a parallel STL was released as part of the Intel OneAPI DPC++: GitHub - oneapi-src/oneDPL: oneAPI DPC++ Library (oneDPL) https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/dpc-library.html
I think the Intel and gcc-9 compilers should already have support for this.
Ok thanks. Maybe we should start a thread “the inevitable rise of C++ in HPC”.
I am not competent concerning C++, but I had found that paper recently:
Nice, the paper pertains to SWIG mentioned several times elsewhere of this forum.
Alas the xkcd.com cartoon re: automation applies ever more strongly with all C++ libraries generally given their complexity and especially with automated interfaces to them.
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.
I wonder if the performance issues are again due to poor potential for vectorization, similar to the issue explained here: Comments in ResearchGate about Fortran - #5 by ivanpribec
A while ago I did some experiments with character validation routines (checking if a character belongs to letters, numerals, whitespace, etc.) and I was surprised to learn that with the right implementation the speed was very close to C++: GitHub - ivan-pi/fortran-ascii: Fortran routines for manipulating ASCII characters (future pull request to fortran-lang/stdlib https://github.com/fortran-lang/stdlib). Processing a sequence of 10 million characters, both Fortran and C++ could reach speeds of around 0.5 billion characters per second.
If you have any experience using the varying string type I would solicit your feedback on a recent pull request at the stdlib project: Implement non-fancy functional string type by awvwgk · Pull Request #320 · fortran-lang/stdlib · GitHub. A link to the mentioned comp.lang.fortran thread would also be valuable, if you can find it by any chance.
Thanks much for the info, I will check the linked pages first and dig my old test programs (which I guess I still have on some disks…).