Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework C++ and Python interfaces #112

Open
robertodr opened this issue Jan 29, 2020 · 0 comments
Open

Rework C++ and Python interfaces #112

robertodr opened this issue Jan 29, 2020 · 0 comments

Comments

@robertodr
Copy link
Contributor

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 XCFunctional struct 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!

@robertodr robertodr mentioned this issue Jan 29, 2020
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant