How to handle non-member operators ?

[farinaleo]

Hi, I'm still using the lib for binding my code but I cannot bind non-member operators.
Have you planned to add it?
How can I contribute to add the feature?

exemple

class Hello {
    public:
        Hello();
        Hello(int c);

    private:
        int c;

};

Hello operator+(int a, Hello b);

[pthom]

Hi,

I have not planned to add support for non-member operators at the moment.

Option 1: a workaround by adding radd to your class

Example:

def play() -> None:
    options = litgen.LitgenOptions()
    options.srcmlcpp_options.header_filter_acceptable__regex += "|GENERATE_PYTHON"

    code = """
// Define GENERATE_PYTHON somewhere when generating python bindings

class Hello 
{
public:
    Hello();
    Hello(int c);

    #ifdef GENERATE_PYTHON
    // For python bindings, add a __radd__ method to support int + Hello
    Hello __radd__(int a);
    #endif

    int c;
};

Hello operator+(int a, Hello b)
{
    return Hello(a + b.c);
}

#ifdef GENERATE_PYTHON
// __radd__ is implemented in terms of the already existing external operator+
Hello Hello::__radd__(int a)
{
    return a + *this;
}
#endif
        """
    generated_code = litgen.generate_code(options, code)
    print(generated_code.stub_code)

    print(generated_code.pydef_code)

Option 2: work on adding this feature

How can I contribute to add the feature?

It would probably be a little tricky. Here are some quick hints.

the warning is raised at:

# adapted_function.py
class AdaptedFunction(AdaptedElement):
    ...
    def __init__(
     ...
        operators.raise_if_unsupported_operator(self.cpp_adapted_function)
    ...

# operators.py
def raise_if_unsupported_operator(cpp_function_decl: CppFunctionDecl) -> None:
    if not cpp_function_decl.is_operator():
        return
    if not cpp_function_decl.is_method():
        cpp_function_decl.raise_exception("operators are supported only when implemented as a member functions")
   ...

If it is external an operator, you should check if

• It has only two arguments
• the second argument is of a known class for which bindings were already emitted.
• at the moment, there is no "memory" of the emitted classes, but it could be added to LitgenContext. See encountered_cpp_enums: you may add encountered_classes

Then you would need to either:

1. somehow alter the pydef binding code + the stub code for the class. Things would get more complex here, since the code for the class was already generated and we would need to modify it after the fact.
2. Do a preprocessing step where we artificially add a C++ method "radd" to the class before generating bindings for it when needed.

As you see I'm a bit uncertain on which approach is the best.

Good luck!

[farinaleo]

Thank you for your advice !!
Adding this feature seems to be possible. When I have time, I will see what I can do

[pthom]

Hi @farinaleo

Just to add another possible solution with the new 0.21.0 release:

Litgen now supports a custom bindings API, which lets you extend generated classes without modifying your C++ headers. This can be useful for handling non-member operators by manually exposing them as Python special methods.

For example, if you have:

struct Hello {
    int c = 0;
};

Hello operator+(int a, Hello b);

You can inject a radd method into the Python binding like this:

options.custom_bindings.add_custom_code_to_class(
    qualified_class="Hello",
    stub_code='''
        def __radd__(self, a: int) -> "Hello": ...
    ''',
    pydef_code="""
        LG_CLASS.def("__radd__", [](const Hello& self, int a) {
            return a + self;   // calls the non-member operator+
        });
    """,
)

This way, int + Hello() works in Python, even though the operator is not a class member in C++.

See the manual section Manually add custom bindings