With #98 in the pipeline, we have new C and Fortran API which are identical and behave (to the extent of my testing and knowledge) exactly the same.
The code for the C++ and Python interfaces, however, looks quite silly and contrived at the moment.
This is a summary of the current state of affairs:
I have decoupled the C++ implementation from the C API, which allows to do more sophisticated stuff C++-side. In practice this means that there's a XCFunctionalstruct with C++ functions under the xcfun namespace. These methods are allowed to use all the fancy C++11 stuff (except runtime type identification (RTTI) and exceptions). See XCFunctional.hpp for the code.
The C(Fortran) API wraps XCFunctional as an opaque pointer of type xcfun_t(type(c_ptr)) The C++ functions handling this object are wrapped in XCFunctional.cpp with a cast from the opaque type to the actual type XCFunctional. (@bast will recognize the context API pattern at work, see XCFunctional.cpp for the code)
The Python interface wraps the C++ object XCFunctional, some of the C++ functions, and some of the C API functions. The code in export_xcfun.cpp is thus a bit confusing to read.
Where I would like to go:
Rework the C++ layer so that we have a proper XCFunctional object. We have to decide whether we want a class with data members and methods or a struct with free functions is fine too.
The XCFunctional object should be modeled with the Python usage patterns in mind, meaning that the code with the bindings to Python should be as concise as possible and the use of the class be smooth in both languages.
C/Fortran APIs come later on top of the C++ API. The C API is a flattening of the C++ API with the context API pattern. The Fortran API is a mere set of interfaces to get the types correct in Fortran hosts.
I am not really sure how to parcel out these work items/wish list. Working with the C++ code is not exactly trivial at the moment. There is a lot of preprocessor magic going on that I do not understand at all, so it's really scary to do anything substantial!
With #98 in the pipeline, we have new C and Fortran API which are identical and behave (to the extent of my testing and knowledge) exactly the same.
The code for the C++ and Python interfaces, however, looks quite silly and contrived at the moment. This is a summary of the current state of affairs:
XCFunctionalstructwith C++ functions under thexcfunnamespace. These methods are allowed to use all the fancy C++11 stuff (except runtime type identification (RTTI) and exceptions). SeeXCFunctional.hppfor the code.XCFunctionalas an opaque pointer of typexcfun_t(type(c_ptr)) The C++ functions handling this object are wrapped inXCFunctional.cppwith a cast from the opaque type to the actual typeXCFunctional. (@bast will recognize the context API pattern at work, seeXCFunctional.cppfor the code)XCFunctional, some of the C++ functions, and some of the C API functions. The code inexport_xcfun.cppis thus a bit confusing to read.Where I would like to go:
XCFunctionalobject. We have to decide whether we want aclasswith data members and methods or astructwith free functions is fine too.XCFunctionalobject should be modeled with the Python usage patterns in mind, meaning that the code with the bindings to Python should be as concise as possible and the use of the class be smooth in both languages.interfaces to get the types correct in Fortran hosts.I am not really sure how to parcel out these work items/wish list. Working with the C++ code is not exactly trivial at the moment. There is a lot of preprocessor magic going on that I do not understand at all, so it's really scary to do anything substantial!