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

[Core] Making regitry able to handle type and non-type template args #13121

Closed
wants to merge 2 commits into from

Conversation

roigcarlo
Copy link
Member

📝 Description
*** This is to be merged to core/new-linear-strategy *** first
Modifies the auto-register code to be able to handle classes with type and non-type template arguments (aka ``MyClass<3,Foo>`)

There is a caveat, non-type parameters need to be passed with its type explicitly stated (see ApplyRayCastingInterfaceRecognitionProcess). for example:

template<std::size_t TDim> 
class ...
....
KRATOS_REGISTRY_ADD_TEMPLATE_PROTOTYPE("Processes.KratosMultiphysics", Process, ApplyRayCastingInterfaceRecognitionProcess<TDim>, TDim)

// becomes

KRATOS_REGISTRY_ADD_TEMPLATE_PROTOTYPE("Processes.KratosMultiphysics", Process, ApplyRayCastingInterfaceRecognitionProcess<TDim>, int[TDim])

I need to do this because it is imposible (to the best of my knowldge) to use variadric templates which mix the two types of template arguments. If someone knows how to do it better I am all ears (@sunethwarna, @mpentek, @loumalouomega looking at you guys ;))

Sample output:

template class Kratos::ApplyRayCastingInterfaceRecognitionProcess<2>;
template class Kratos::ApplyRayCastingInterfaceRecognitionProcess<3>;

Becomes:

['ApplyRayCastingInterfaceRecognitionProcess<3>', 'ApplyRayCastingInterfaceRecognitionProcess<2>'] 

Also ping @ddiezrod because you are the only one using this right now :D

@roigcarlo roigcarlo requested a review from a team as a code owner February 12, 2025 13:15
@roigcarlo roigcarlo requested review from a team and removed request for a team February 12, 2025 13:15
@loumalouomega
Copy link
Member

There is a conflict already

@rubenzorrilla
Copy link
Member

Shouldn't we add this to the master rather than to my branch?

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

Successfully merging this pull request may close these issues.

3 participants