[J3] [EXTERNAL] Re: Clarification on F18/017

[Vipul Parekh]

On Tue, Jun 9, 2020 at 8:39 AM Clune, Thomas L. (GSFC-6101) via J3 <
j3 at mailman.j3-fortran.org> wrote:

> ..  There are many things in Fortran that would be surprising to C/C++
> programmers.  (Non) short-circuiting of conditionals being the first one
> that comes to mind,  but I could rattle off half a dozen off the top of my
> head.   Those with more experience could probably rattle off dozens. ..
>
Now, with my limited experience of looking at C++ code, I don’t recall ever
> seeing an output statement in a destructor, and would generally only expect
> such as a debugging aid that would eventually be removed.    I would expect
> the same in quality Fortran code.   Unless you put in a print statement you
> cannot know the order of finalization.    So the famed C++ coder is only
> going to be surprised if they become suspicious of FINAL in the first
> place.     ..
>


C++ coders using their standard-conforming processors don't have to worry
about such things because the C++ standard itself takes great effort to
ensure the destruction of objects take place in the *reverse order* of
construction c.f. section 15.6.2 Initializing bases and members in N4659
WG21 document, "Working Draft, Standard for Programming Language C++,"
2017-03-21.

Whereas with Fortran, the burden gets effectively placed on the code
designer(s) and programmer(s) to implement both initialization as well as
FINAL procedures if they want to completely be sure the base(s) and
member(s) (aka component(s) and parent(s)) in their 'classes' (aka derived
types) get 'instantiated' and 'cleared' in both a memory efficient as well
as an invulnerable manner.  Looking at 18-007r1 document however, I'm
unsure whether this interp F18/017 is the right place to start considering
such matters.

My view is the state of affairs in Fortran is a *larger* issue that needs
to be addressed with a major improvement to the language incorporating
facilities that provide a new *direct* construction and initialization (as
opposed to explicit which I think has forever been "corrupted" by implied
SAVE) of objects of derived types in Fortran where suitable semantics and
rules with ordering of base(s) and member(s) "instantiation" for the
practitioners of Fortran can be developed.  For only then can the
"destruction" and the consequent *ordering* of finalization be tackled.

In the meantime, if anyone wants to "dabble with" C++ 'behavior' for the
code example provided by Ondrej and Neil, here's one example where I try to
live up to the axiom "an engineer can Fortran in any programming
language".  Note I feel 'unique_ptr' in C++ (that came much later in
C++11/C++14) is the closest analogue to ALLOCATABLEs without TARGET in
Fortran (which became 'usable' starting 2003 standard revision), hence its
use in this example:

--- begin C++ example ---
#include <memory>
#include <iostream>
using namespace std;

class objectA {
public:
   ~objectA()
   {
      std::cout << "A";
   }
};

class objectB {
public:
   ~objectB()
   {
      std::cout << "B";
   }
};

class parent {
public:
   ~parent()
   {
      std::cout << "P";
   }
};

class child : parent {
private:
   std::unique_ptr<objectA> pA;
   objectB B;
public:
   child() : parent() {
      pA = std::unique_ptr<objectA>(new objectA());
   };
   void foo() { std::cout << "Example toward clarification on F18/017" <<
"\n"; }
   ~child()
   {
      std::cout << "C";
   }
};

void sub();

int main()
{
   sub();
   return EXIT_SUCCESS;
}

void sub() {
   std::unique_ptr<child> c(new child());
   c->foo();
}
--- end C++ example ---

Two C++ processors I attempted gave the 'CBAP' output.  Here's the program
response using GCC:

--- begin console output ---
C:\Temp>gcc -Wall f18_017.cpp -lstdc++ -o f18_017.exe

C:\Temp>f18_017.exe
Example toward clarification on F18/017
CBAP
C:\Temp>
--- end output ---

Regards,
Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200610/7ffc5ba5/attachment.htm>