Template Wrapping about pythonocc-generator HOT 9 CLOSED

I've worked with ITK which is a image processing library wrapped by swig, which uses templates extensively. It might provide an interesting analogy?

in the old days, the project used gccxml for parsing and has recently moved to it successor castxml. itk's wrapper generation code is here

perhaps this can provide as reference to manage templates?

when parsing the C++ code, its possible to get the list of arguments, that is the types that are parameters for the template?

<< hope you dont mind me pitch in here and there, i do realize I'm not @tpaviot 😉 >>

from pythonocc-generator.

@lalvarezt I fully agree with you. Moving up the wrapper to the coming oce-0.18 (==occt691) is straight forward, there will be some minor issues that will easily be solved.

In a midterm, I'm a lot more concerned about the latest occt7 version. I'm aware of the major refactoring about the handles, with a intensive use of c++ templates. So far, I did not reallly dive into the wrapping of templates, but hey, I guess this moment gets closer and closer ;-)

To be honest, I did not work enough to have a clear idea about how things should be done. I don't even have a clue about the different solutions that could be investigated. Please @lalvarezt go on with this idea of a pre-static analysis to detect templates. In a first STEP, there's no need to modify the generator, we can work on the pythonocc-core repository, with manual changes to some .i files. When we clearly understand what happens, it will be time for an automation of the wrapper generation.

from pythonocc-generator.

@jf--- thanks for introducing castxml, I was not aware of that project. And ITK is certainly a good place to grab good ideas with SWIG and c++

from pythonocc-generator.

@jf--- Any help is appreciated.

from pythonocc-generator.

@tpaviot @jf--- I've been looking into the issue, and the problem is not in the CppHeaderParser library, is in the way SWIG handles templates. CppHeaderParser provides all the necessary info for wrapping the templates (type, arguments, etc). The problem then is to know wich of the types will be used beforehand, so we can generate the corresponding code.

@tpaviot I'll start with the static parsing of the code to see if something pops up.

from pythonocc-generator.

@lalvarezt , is there news on handling templates?
Perhaps we should focus on some design / experimental implementations to advance this topic.
Possible @rainman110 has an interesting outlook on the topic?

from pythonocc-generator.

@lalvarezt I started looking at the template issue. I just pushed the latest CppHeaderParser release (previous one had an error handling templates).

Templated class methods should don't be that hard to wrap.

Not the same for templated classes (for instance NCollection_*), it seems to be a bit more difficult.

IMO we should go step by step. The first one is to wrap templated methods with a predefined and default "list" of accepted types, e.g. float, int, bool, str. Additionnal types can be specified in the Modules.py script.

I'm about to open a PR related to this, I will notify you as soon as it is ready for review.

from pythonocc-generator.

@tpaviot That's very good news, I was working with the latest CppHeaderParser release, that's why I didn't notice the error. Adding specialized types in the Modules.py it's a great idea.

from pythonocc-generator.

See Issue #49

from pythonocc-generator.