# Fortran and C++ **URL:** \ **Category:** Uncategorized\ **Created:** [February 8, 2021, 8:51pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685 "2021-02-08T20:51:48Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![une](https://avatars.discourse-cdn.com/v4/letter/u/b5e925/32.png) [@une](https://fortran-lang.discourse.group/u/une)\ **Post date:** [February 8, 2021, 8:51pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/1 "2021-02-08T20:51:48Z")
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](https://github.com/wavebitscientific/datetime-fortran/blob/master/src/strptime.cpp) ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [February 8, 2021, 9:11pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/2 "2021-02-08T21:11:45Z")
> [@une](#): > > … 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 … @une , You may want to review this post from several years ago: [Quote:\ **Author:** ![epagone](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/epagone/32/252_2.png) [@epagone](https://fortran-lang.discourse.group/u/epagone)\ **Post date:** [February 9, 2021, 11:47am UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/3 "2021-02-09T11:47:27Z") @FortranFan is spot on. However, you might want to have a look at [Shroud](https://shroud.readthedocs.io/en/latest/) (very interesting and promising but I had zero time to dedicate to fiddle a little bit with it ☹ ) ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [February 9, 2021, 4:01pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/4 "2021-02-09T16:01:45Z")
“Shroud” seems interesting, but it may be better to not play with it when busy… > **[Automation](https://xkcd.com/1319/)** > > 'Automating' comes from the roots 'auto-' meaning 'self-', and 'mating', meaning 'screwing'. ---
**Author:** ![epagone](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/epagone/32/252_2.png) [@epagone](https://fortran-lang.discourse.group/u/epagone)\ **Post date:** [February 9, 2021, 4:09pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/5 "2021-02-09T16:09:15Z")
😁 Exactly, been there, done that… multiple times 😉 ---
**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 9, 2021, 5:22pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/6 "2021-02-09T17:22:11Z")
The same xkcd comic is shown in the [slides](https://github.com/LLNL/shroud/blob/develop/pdf/Shroud-forcon.pdf) for Shroud from FortranCon. 😉 ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [February 9, 2021, 6:22pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/7 "2021-02-09T18:22:06Z")
@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](https://github.com/fortran-lang/fpm/issues/353) ---
**Author:** ![rcs](https://avatars.discourse-cdn.com/v4/letter/r/d2c977/32.png) [@rcs](https://fortran-lang.discourse.group/u/rcs)\ **Post date:** [February 10, 2021, 12:06pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/8 "2021-02-10T12:06:09Z")
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](https://fortran-lang.discourse.group/t/the-counter-intuitive-rise-of-python-in-scientific-computing/469/76) ---
**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 10, 2021, 12:46pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/9 "2021-02-10T12:46:08Z")
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. ---
**Author:** ![rcs](https://avatars.discourse-cdn.com/v4/letter/r/d2c977/32.png) [@rcs](https://fortran-lang.discourse.group/u/rcs)\ **Post date:** [February 10, 2021, 12:56pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/10 "2021-02-10T12:56:12Z")
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. ---
**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 10, 2021, 1:25pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/11 "2021-02-10T13:25:36Z")
> [@rcs](#): > > But the main problem with STL is that it is, to my knowledge, not threaded. 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](https://github.com/oneapi-src/oneDPL) I think the Intel and gcc-9 compilers should already have support for this. ---
**Author:** ![rcs](https://avatars.discourse-cdn.com/v4/letter/r/d2c977/32.png) [@rcs](https://fortran-lang.discourse.group/u/rcs)\ **Post date:** [February 10, 2021, 1:50pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/12 "2021-02-10T13:50:15Z")
Ok thanks. Maybe we should start a thread “the inevitable rise of C++ in HPC”. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [February 12, 2021, 5:33pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/13 "2021-02-12T17:33:46Z")
I am not competent concerning C++, but I had found that paper recently: > **[Automated Fortran--C++ Bindings for Large-Scale Scientific Applications](https://arxiv.org/abs/1904.02546)** > > Although many active scientific codes use modern Fortran, most contemporary > scientific software "libraries" are implemented in C and C++. Providing their > numerical, algorithmic, or data management features to Fortran codes requires > writing and... ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [February 12, 2021, 7:04pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/14 "2021-02-12T19:04:54Z")
> [@vmagnin](#): > > … I had found that paper recently … Nice, the paper pertains to SWIG mentioned several times elsewhere of this forum. Alas the [xkcd.com](http://xkcd.com) cartoon re: automation applies ever more strongly with all C++ libraries generally given their complexity and especially with automated interfaces to them. ---
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [February 12, 2021, 7:56pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/15 "2021-02-12T19:56:52Z")
> [@FortranFan](#): > > Nice, the paper pertains to SWIG mentioned several times elsewhere of this forum. 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. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [February 13, 2021, 11:28pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/16 "2021-02-13T23:28:55Z")
> 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. ---
**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 14, 2021, 4:04pm UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/17 "2021-02-14T16:04:40Z")
> [@septc](#): > > 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. 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](https://fortran-lang.discourse.group/t/comments-in-researchgate-about-fortran/697/5) 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)](https://github.com/ivan-pi/fortran-ascii#speed-vs-different-implementation-approaches). Processing a sequence of 10 million characters, both Fortran and C++ could reach speeds of around 0.5 billion characters per second. > [@septc](#): > > 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, If you have any experience using the varying string type I would solicit your feedback on a recent pull request at the stdlib project: [https://github.com/fortran-lang/stdlib/pull/320](https://github.com/fortran-lang/stdlib/pull/320). A link to the mentioned comp.lang.fortran thread would also be valuable, if you can find it by any chance. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [February 19, 2021, 6:33am UTC](https://fortran-lang.discourse.group/t/fortran-and-c/685/18 "2021-02-19T06:33:42Z")
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…).