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

Split of type and method declaration for parametric types #138

Open
grasph opened this issue Dec 20, 2023 · 1 comment
Open

Split of type and method declaration for parametric types #138

grasph opened this issue Dec 20, 2023 · 1 comment

Comments

@grasph
Copy link

grasph commented Dec 20, 2023

Hello Bart,

In the code generated by Wrapit and for non-parametric types, we proceed first with the wrap declaration (add_type()) of all types and proceed in the second step to the method declarations (method()). This ensures that all types needed for a method are in place when declaring it.

It does not work for non-parametric types because type declaration is finalized by the apply() call that declares also the methods. The method apply() cannot be called multiple times. Otherwise, we could call it with a functor that does nothing to proceed with the type declaration finalization. The call will also define the default methods, but that should not be a problem.

Beyond convenience of a two-step approach, separation of type and method declaration is mandatory in case of cyclic dependency like in the example below.

template<typename> class B;

template<typename T>
struct A{
  void f(const B<T>&){}
};


template<typename T>
struct B{
  void f(const A<T>&){}
};

template struct A<int>;

Would it be possible to add support for multiple call to apply() or another way to allow a two-step declaration?

Let me know in case there is already a way to achieve this with the current CxxWrap version.

Regards,

Philippe.

@sloede
Copy link
Contributor

sloede commented Jan 1, 2024

Thanks for raising this issue. I came across the exact same question - have you found a way around this yet? Otherwise it would be great to learn if this is already possible or if there is another possibility to make it work in case of such mutually dependent types.

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

2 participants