OO capabilities of Fortran 2018 vs c++

Help
1

Hi,
Are the OO capabilities of Fortran 2018 are as robust as C++? Of course I am not speaking about ‘templates’. By robust I mean - any OO mechanism that is implemented in C++ can also be implemented in Fortran and with minimum loss in performance ?
I am working in the area of Finite Element Analysis and structural engineering and a big fan of Fortran. But all the robust, tested open source FEM software that I use are completely programmed in C++ and I get bogged down by seeing the code complexity. I want to implement some small FEM codes for my own understanding in Fortran using the similar logic - like Abstract classes to avoid long if-then-else codes and so on… But I, like many people lack time to now get into Fortran OO and experiment it. So I am seeking your advice about the current state of OO capabilities of Fortran, it’s future and compiler support. Is it worth getting into it? I am not looking for HPC any near future. Or shall I continue with C++ ?
I am running in a windows machine with intel compiler.

6 Likes
2

The following papers make the case that modern Fortran
OO is more than adequate for writing OO based Finite
Element codes. There have probably been others since these
were published.

Badia et al, “FEMPAR: An Object-Oriented Parallel Finite Element Framework,”
Archives of Computational Methods in Engineering , V26, pp 195-271 (2018)

This paper is open-access and the PDF is available at:

Its about 77 pages long and has detaled examples of Fortran OO code
to illustrate various aspects of the framework.

FEMPAR is open-source and can be downloaded from github at:

Yuan and Fish, “Nonlinear multi-physics finite element code architecture in object oriented Fortran environment,” Finite Elements in Analysis and Design, Volume 99, pp 1-15, July 2015.

Also see Z. Yuan’s dissertation The multi-scale damage mechanics in object-oriented Fortran Environment Columbia University, 2016.

He found that for linear-elastic problems his Fortran 2003 implemenation was 5 to 16 times
faster than his C++ implementation on the same test problems.

Nie et al, “Development of an object-oriented finite element program with adaptive mesh refinement for multi-physics applications,” Advances in Engineering Software, Vol. 41, no. 4, pp. 569-579, April 2010.

5 Likes
3

The ElmerFEM (GitHub - ElmerCSC/elmerfem: Official git repository of Elmer FEM software) finite element software suite is also mostly Fortran along with some C and C++.

5 Likes
5

I posted a paper Emulating Multiple Inheritance in Fortran 2003/2008 but am unqualified to evaluate it, as a Fortranner without CLASS.

3 Likes
6

Thank you @Beliavsky, @ivanpribec , @septc , @rwmsu . May be I will take some time off and get into OOP in Fortran.

8

You know more than I do about the multiple inheritance, but the designers of languages with MI had their reasons for including it. I wonder if programmers or academic computer scientists have reached a consensus about the value of MI. The ISO C++ site discusses when to use MI.

12

Thanks a lot @difference-scheme for your detailed answer. I will try to emulate the best practices that you have shown here.

13

@difference-scheme, @septc would you be interested in helping the generics subgroup of the Fortran Standards Committee with designing “traits” / generics for Fortran?

The main repository is here: GitHub - j3-fortran/generics, here are some overview documents:

3 Likes
14

Two cents from a finite element programmer:

  1. OOP is not magic. It is only a style of organization. It sometimes suits the problem naturally, though less often than many people think. I have seen many unnecessary classes in FEM codes. It is natural to have classes for element, nodes or even shape functions. But, I don’t get it when I see a single use problem class. Someone may call it a design pattern. To me it looks force-fitting OOP. In Fortran, modules, save attribute and subroutines often allow me to get away with such cases.
  2. Original OOP of smalltalk is a beautiful concept, perhaps more beautiful than pure functional style. There everything is an object. OOP in popular languages, especially C++, is broken. Here, everything cannot be an object. The question what should be an object and what should not be leads to a lot of confusion.
  3. You seem to think that OOP will save you from long boiler-plate code. But, there is a cost for that. Spaghetti logic is one. Search chimapanzee-banana metaphor of OOP. In short, you may end up adding more lines than you expect to save. That is not to say there is no value to adding classes. Gains in reuseusability and abstraction are some.
  4. I’m too inexperienced a programmer to criticize a language used by so many legends. Still, I cannot hold myself from showing grudges against C++. They seem to be after every feature under the sun, overburdening poor guys like us under the heap of features, often from contrasting styles. They started by adding objects, then came generics and now want to make it functional!

In short, (if you) use OOP but do not overuse it. Fortran has quite sufficient of it!
The answer is quite opinionated. But, I stand here to be corrected.

8 Likes
15

My thanks also to @difference-scheme for his detailed explanation and hopefully his standard proposal will be given serious consideration. Maybe someone who was on J3 at the time the OOP facility was being designed can enlighten us as to why certain choices were made particulary why we ended up with OOP based on implementation inheritance when the Gang of Four advice regarding favoring composition and aggregation over inheritance as well as programming to an interface and not an implementation were known at the time. I’ve just about given up on using abstract interfaces because they force you into select type hell in situations you think it wouldnt be needed.

2 Likes
19

The section 2.2. The limitation of the OOP in Fortran 2003 in the paper by Yuan and Fish (2015) can be taken literally as dealing with the mundane matter of authoring OO classes using Fortran 2003. As such, their points have been addressed by Fortran 2008 and the current 2018 revision. SUBMODULEs directly tackle both the limitations listed by the authors. In addition, current standard includes other facilities that can obviate the need to pursue OO in certain use cases involving scientific and technical programming.

Hopefully Fortran 202Y will provide other features so that Fortranners can be even more judicious when it comes to the programming paradigms needed in their codes, that they will have all the means to focus closely on parallel and functional solutions topped lightly with generic metaprogramming aspects and only aided, as needed, by utilities adopting OO with shallow hierarchies.

2 Likes