hxcpp
hxcpp copied to clipboard
HaxeFoundation
Compiler switch to put generated Haxe classes into a child namespace
Currently hxcpp places many classes in the root C++ namespace. Many of these classes have common names like "String", "File", "Object", and "Class". This creates conflicts between hxcpp and other C++ code. The lack of namespace-compliance also makes hxcpp unreliable for production code, because there is no guarantee that its output will work with existing, namespace-compliant code bases.
Ideally in the long run these classes would be put into a child namespace by default, but since so far hxcpp has been using the root namespace, the only viable solution now would be a compiler switch that toggles which namespace (root or child) the generated Haxe classes are placed in.
Stumbled upon this today with String which was also present in a codebase i was trying to integrate with... Could we just put everything in hx:: namespace?
Dynamic, String, null and Math_obj are in the top-level namespace. The first two are going to be pretty hard to shift. I could possibly put the implementation into a namespace and have a global typedef, but is this going to help? It would still prevent current haxe-gen code from seeing your alternate String implementation, although non-haxe-gen code could be made to work with both.
What does -D include-prefix do?
https://github.com/HaxeFoundation/haxe/blob/555c9153342a2f7e82bf89258f442cfd947673df/src-json/define.json#L265-L270
We have -D no-root for cs/java and -D php-prefix for php. I think it's time to unify them.
@hughsando i don't have much experience with c++, so it might be nonsense, but couldn't we "just" put everything in hx namespace and then generate using namespace hx in c++ modules coming out of Haxe?
The current haxe compiler explicitly puts the string in the global namespace with "::String". So you would need a haxe compiler update (2 years?) to fix this properly. Backwards compatibility is an issue (hxcpp git should work with 3.4.7) and "using namespace hx" could potentially undo all the good work of putting things in hx namespace.
A similar solution could work - where String is put in the hx namespace, and we use a global typedef for the haxe-generated code so sees a "typedef hx::String String" line. You would then need to hide this typedef from your native code somehow. But then your native code would not be able to include both the haxe-gen headers and the native headers in the same file.
It depends to some extent on what you are trying to do, but isolating the haxe-gen code from the native code is probably the best way of doing it. It is some work - creating API header(s), writing some native glue code "inside" the hxcpp code and then compiling to a lib/dll. But what you end up with is a well-defined Api and a library you can link in that is decoupled from any hxcpp version or changes or namespaces (unless you get a linking error).
Hi folks,
I just stumbled upon this related to dynamic libraries on Linux and Macos.
If I use hxcpp to generate one and the loading Host application also exposes a ::String Symbol(in my case it does) the Haxe runtime will just explode when setting up and working with ::String, since the Symbols will be picked out of the Host.
On Linux I can use -Bsymbolic to some extend but there is no option like that for recent MacOS(at least not that Im aware of).
In ideal world any project that involves dynamic linking should not define & expose general terms "String" or "Dynamic" or "Array".
This is kinda sad, since that means I cant really use hxcpp's out of the box dynamic library compilation, which works super nice under windows, obv :(
