Fri, 03/02/2018 - 15:43
In PresentationFramework from .NET 4.5 a namespace called Standard has been added. Admittedly, there might not be too many out there using occt from c++/cli (or are there?), but for those which do and also use the PF, this will clash with the class Standard in the global namespace from occt.
Looking at the occt roadmap, this certainly is not the most important issue but in the long term i think the project would benefit if all very common names, no matter if they are types, macros or namespaces, would be refactored to become more unique.
In the special case of the class Standard, i tried this to see how complex it is and it turns out moving it in a namespace called opencascade and changing about 100 places (including help) where this is directly used took me about 10 minutes (excluding compilation and tests).
I'm aware that such a change would probably require many users to change their code as well, but putting a using namespace opencascade in some global header(s) would solve that hackishly and global replace also wouldn't take too long.
I would be happy to post my changes to https://dev.opencascade.org/index.php?q=home/get_involved but hope to get some opinions first.
Wed, 03/07/2018 - 17:09
I don't think that renaming something in OCCT is a good idea to workaround name collisions with .NET. In such a way OCCT should rename a plenty of other APIs - you may find that standard system headers for WinAPI and XLib already define many common names as macros introducing weird collisions. Renaming everything that collides might be too painful and unreasonable.
I haven't worked on this issue, but I believe there should be other ways to workaround collisions, which should be tried first, before affecting OCCT C++ source code.