You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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:
XCFunctional
struct
with C++ functions under thexcfun
namespace. These methods are allowed to use all the fancy C++11 stuff (except runtime type identification (RTTI) and exceptions). SeeXCFunctional.hpp
for the code.XCFunctional
as an opaque pointer of typexcfun_t
(type(c_ptr)
) The C++ functions handling this object are wrapped inXCFunctional.cpp
with a cast from the opaque type to the actual typeXCFunctional
. (@bast will recognize the context API pattern at work, seeXCFunctional.cpp
for the code)XCFunctional
, some of the C++ functions, and some of the C API functions. The code inexport_xcfun.cpp
is thus a bit confusing to read.Where I would like to go:
XCFunctional
object. We have to decide whether we want aclass
with data members and methods or astruct
with free functions is fine too.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.interface
s 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!
The text was updated successfully, but these errors were encountered: