4 ms·

I'm puzzled. Operators in C++ are just function calls. How do they lead to a complicated binary interface? I only watched three minutes of the video but he does

I'm puzzled. Operators in C++ are just function calls. How do they lead to a complicated binary interface? I only watched three minutes of the video but he doesn't talk about operators during that period.

dnautics 6y ago
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?
pirocks 6y ago
Because you need to specify the types of the operator in the symbol name as well.
- tapirl 6y ago
  But isn't the name is still needed if you define a function instead of overloading the operator?
- thayne 6y ago
  that just means you need a mangled name in the symbol table. I don't really consider that part of the "binary interface". The big problem with this in, for example, c++, is that the name is mangled in an implementation defined way. If the way the operator name is mangled is well specified, there's no reason it couldn't be used as a C function from another language.
  - matheusmoreira 6y ago
    > that just means you need a mangled name in the symbol table That alone is already enough to stop most if not all foreign language interfaces from resolving a symbol to a function pointer. That's the simplest hurdle to overcome. There are also complex mechanisms to deal with such as virtual method tables that figure into the calling conventions of overridable methods. Not even C++ compilers manage to keep the ABI stable between every compiler version: sometimes libraries compiled with a new version cannot be used with software compiled by an old version. Rust doesn't even have an ABI specification yet.
    - thayne 6y ago
      virtual method tables and operator overloading are orthogonal problems. Sure in many languages operator overloading is done using virtual methods, but it doesn't have to be. Operator overloading can dispatch based on static types rather than dynamic types. That said, I do wish that there was a standardized way to expose vtables across foreign language boundaries. Although, I understand that differences in how vtables work across different languages, or even different implementations of the same language (cough cough c++ cough cough) would make creating a useful standard difficult.

dnautics 6y ago

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?

pirocks 6y ago

Because you need to specify the types of the operator in the symbol name as well.

tapirl 6y ago
But isn't the name is still needed if you define a function instead of overloading the operator?
thayne 6y ago
that just means you need a mangled name in the symbol table. I don't really consider that part of the "binary interface". The big problem with this in, for example, c++, is that the name is mangled in an implementation defined way. If the way the operator name is mangled is well specified, there's no reason it couldn't be used as a C function from another language.
- matheusmoreira 6y ago
  > that just means you need a mangled name in the symbol table That alone is already enough to stop most if not all foreign language interfaces from resolving a symbol to a function pointer. That's the simplest hurdle to overcome. There are also complex mechanisms to deal with such as virtual method tables that figure into the calling conventions of overridable methods. Not even C++ compilers manage to keep the ABI stable between every compiler version: sometimes libraries compiled with a new version cannot be used with software compiled by an old version. Rust doesn't even have an ABI specification yet.
  - thayne 6y ago
    virtual method tables and operator overloading are orthogonal problems. Sure in many languages operator overloading is done using virtual methods, but it doesn't have to be. Operator overloading can dispatch based on static types rather than dynamic types. That said, I do wish that there was a standardized way to expose vtables across foreign language boundaries. Although, I understand that differences in how vtables work across different languages, or even different implementations of the same language (cough cough c++ cough cough) would make creating a useful standard difficult.