Nef 3: performance gain using std::variant for Object_handle

[GilesBathgate]

Summary of Changes

Refactored CGAL::Object_handle within the Nef_2, Nef_3, and Nef_S2 packages to use an std::variant based approach. This introduces dependency injection for Object_handle instantiation, replacing explicit make_object(...) function calls with direct template constructors (e.g., Object_handle(...)) across several key subcomponents.

Switching from the std::shared_ptr<boost::any>> to std::variant<std::monostate,...> achieves a 7% to 8% performance improvement when processing the intersection of a shifted grid of spheres, while utilisng the same memory footprint.

Key modifications include:

• Nef_2: Updated the point locator subroutines (PM_point_locator.h, PM_decorator.h) to yield typed Object_handle responses.
• Nef_3: Adapted SNC_structure, SNC_decorator, SNC_point_locator, and SNC_io_parser to instantiate the parameterized Object_handle instead of untyped handles.
• Nef_S2: Updated sphere map decorators, overlayer algorithms, and point locators to integrate the new parameterized handle syntax.

Release Management

• Affected package(s): Nef_2, Nef_3, Nef_S2, and Convex_decomposition_3
• Issue(s) solved (if any): Performance (7%–8% speedup on shifted grid of spheres intersection)
• License and copyright ownership: CGAL

[afabri]

What is the gain ?

[GilesBathgate]

What is the gain ?

Its 7% to 8% improvement using the intersection of a shifted grid of spheres, but I need to fix for Nef_2 before submitting the final PR.

[sloriot]

Successfully tested in CGAL-6.3-Ic-31

[sloriot]

@afabri if there is no public API, I'd got for a direct replacement, no wrapper.

[GilesBathgate]

@sloriot / @afabri I make the wrapper to be compatible with the public api exposed by locate:

https://doc.cgal.org/latest/Nef_3/Nef_3_2nef_3_point_location_8cpp-example.html

[sloriot]

@sloriot / @afabri I make the wrapper to be compatible with the public api exposed by locate:

https://doc.cgal.org/latest/Nef_3/Nef_3_2nef_3_point_location_8cpp-example.html

@afabri if Nef::Object_handle == std::variant then we'd only need to provide the assign functions for backward compatibility, while deprecating them. What do you think?

https://doc.cgal.org/latest/Nef_3/classCGAL_1_1Nef__polyhedron__3.html#ab540beccfc025bc86af032d69e43ba49

[GilesBathgate]

@sloriot Deprecating CGAL::assign in the public API makes sense. Removing it internally would either require a lot of changes, or could have an assign(Handle, std::variant<...>) overloads for internal use only. I think there would have to be one for each of the possible Type_packs in Nef_2, Nef_S2, Nef_3

[afabri]

I would go for adding assign(Handle, std::variant<...>)