4 ms·

Ok so (seriously), as an experiment, compile a c++ code file that overloads, say, "+" into a .so file (let's keep it to elf format then) and let us know what th

Ok so (seriously), as an experiment, compile a c++ code file that overloads, say, "+" into a .so file (let's keep it to elf format then) and let us know what the "true" name of the corresponding function is by hexdumping the .so

asdfasgasdgasdg 6y ago
Many non-extern C++ names are mangled in .so files, not just operators. I don't see how that affects the ABI (i.e. the calling conventions of the functions). It just means you need to use a library to demangle in order to call the correct function.
- dnautics 6y ago
  Yes, and it is a choice to not support any of them due to complexity. And as a result, you don't get operator overloading. Zig supports C ABI, not C++ ABI.
  - asdfasgasdgasdg 6y ago
    You are confused. Supporting the C ABI and operator overloading are orthogonal. One is about conventions for saving registers and such. The other is about the naming of functions. Zig probably has a principled reason to not support operator customization, but ABI concerns aren't it.
    - dnautics 6y ago
      You were the one that brought up C++, so if I'm confused, it's because what you wrote.
      - asdfasgasdgasdg 6y ago
        I did bring up C++, but I did not bring up operators. The question at hand is whether ABI concerns prevent operator overloading. Plainly, that is not an issue.
weinzierl 6y ago
Just run the hexdump as it is through c++filt and be done. Yes, name mangling is an inconvenience and sometimes it is annoying, but it's not as bad as you make it sound.
- dnautics 6y ago
  and so now you have to add another tool to your toolchain, and if you want to become self-hosting, you have eventually refactor the whole thing, etc... And Zig doesn't generally have plans to support the same types that are available in C++ so realistically the only thing you get is operator and basic function overloading. And in the C++ community, doing exports for interop as "extern C" (in general, because many other languages prefer it) is accepted anyways. Would you make the choice to add that complexity?

asdfasgasdgasdg 6y ago

Many non-extern C++ names are mangled in .so files, not just operators. I don't see how that affects the ABI (i.e. the calling conventions of the functions). It just means you need to use a library to demangle in order to call the correct function.

dnautics 6y ago
Yes, and it is a choice to not support any of them due to complexity. And as a result, you don't get operator overloading. Zig supports C ABI, not C++ ABI.
- asdfasgasdgasdg 6y ago
  You are confused. Supporting the C ABI and operator overloading are orthogonal. One is about conventions for saving registers and such. The other is about the naming of functions. Zig probably has a principled reason to not support operator customization, but ABI concerns aren't it.
  - dnautics 6y ago
    You were the one that brought up C++, so if I'm confused, it's because what you wrote.
    - asdfasgasdgasdg 6y ago
      I did bring up C++, but I did not bring up operators. The question at hand is whether ABI concerns prevent operator overloading. Plainly, that is not an issue.

weinzierl 6y ago

Just run the hexdump as it is through c++filt and be done. Yes, name mangling is an inconvenience and sometimes it is annoying, but it's not as bad as you make it sound.

dnautics 6y ago
and so now you have to add another tool to your toolchain, and if you want to become self-hosting, you have eventually refactor the whole thing, etc... And Zig doesn't generally have plans to support the same types that are available in C++ so realistically the only thing you get is operator and basic function overloading. And in the C++ community, doing exports for interop as "extern C" (in general, because many other languages prefer it) is accepted anyways. Would you make the choice to add that complexity?