My name is FrГ©dГ©ric and I am in charge of the OCCT refactoring project.
We started to look at solutions to replace the Handle classes with a more modern implementation.
The mantis issue for this task is #24023
The different approaches we considered are:
- re-write the current implementation by a template-based one,
- use a third-party smart-pointer such as the ones provided by boost,
- use the standard C++ shared pointer.
Since we do not wish to implement an OCCT-specific solution, for now, we exclude the first approach.
The second solution has the disadvantage to create a dependency to a third-party product, so we also exclude this approach for the moment.
Given that the C++ shared pointer is now standard C++ and supported by at least two major compilers вЂ“ GCC (which implementation is based on boost) and Visual Studio вЂ“, we are going to explore this solution.
The Handle revamping must not impact the existing code. As the C++ shared pointer does not support exactly the same services than the OCCT Handle (e.g. Nullify, Downcast), we could subclass the C++ shared pointer for implementing the OCCT-specific services.
LetвЂ™s call this OCCT shared pointer "handle", with lower-case h. It comes to make the current Handle macro equivalent to this handle template class.
typedef handle<Geom_Point> Handle(Geom_Point);
where the template class handle is a subclass of std::shared_ptr.
As such, by a simple recompilation, the existing OCCT code would be based on the standard C++ shared pointer.
Also, in new code, we can write either
whether we need a pointer compatible or not with the current OCCT Handle.
This new class will be added to a new namespace "occ".
Although it seems not recommended to subclass the C++ shared pointer, we intend to prototype this solution.
Has anyone experienced the C++ shared pointer and/or subclassing it?
Any other remarks are welcomed.