Fri, 04/07/2017 - 12:47
Forums:
We (FreeCAD) are facing some problems with occt7.1.0 on windows. While this version works on linux and mac, windows has some problems with Handles.
Converting argument 2 of "opencascade::handle<TColgp_HArray1OfPnt>" in "Handle_TColgp_HArray1OfPnt &" not possible
It was possible to overcome this problem by using Handle(TColgp_HArray1OfPnt) instead of Handle_TColgp_HArray1OfPnt. But we also facing some run-time warnings:
(eg.: http://forum.freecadweb.org/viewtopic.php?f=4&t=21405&start=90#p167505)
access violation - no RTTI data!
There is no such problem with occt7.0.0
Maybe you have some ideas, what changes between 7.0.0 and 7.1.0 could be related to this problem.
nice regards
Lorenz
Fri, 04/07/2017 - 13:07
- Within older versions of OCCT, Handle() was macros converting name to Handle(Class) -> Handle_Class, where Handle_Class were actual classes generated by WOK or other macros.
- Within OCCT 7.0.0, where WOK has been abandoned and more standard C++ mechanisms have been used for defining OCCT smart pointers,
Handle() now directs to opencascade::handle<Class> template class, while Handle_ classes are defined by DEFINE_STANDARD_HANDLECLASS() as typedef for *compatibility with old code*.
- Within OCCT 7.1.0 DEFINE_STANDARD_HANDLECLASS defining Handle_ has been corrected so that it defines real class inheriting from Handle(),
which is useful within some contexts (e.g. making public is not possible for template classes within C++/CLI) - but this change applies only for Visual Studio compiler (see source code of the macros).
Since Handle() and Handle_ are not the same thing on msvc anymore - it might result in such kind of errors.
The solution is simple - use Handle() where possible instead of obsolete Handle_ (Handle() has been always recommended way for declaring classes - Handle_ is rather internal).
It might be useful looking through the code to clean up all redundant occurrences of Handle_.
Tue, 04/11/2017 - 11:38
thanks for the information. This is exactly what we needed.