5 ms·

I don't see what you're getting at with respect to writing bindings. The whole point of using "static" in that way is to prevent people from using it outside o

I don't see what you're getting at with respect to writing bindings. The whole point of using "static" in that way is to prevent people from using it outside of the file. If you need to call a static function (inline or otherwise) from outside of the compilation unit to use the API, then it's a bug in the API, not a problem with static. I agree with you about pre-processor macros, though.

zabzonk 8mo ago
i think you replied to the wrong comment
yxhuvud 8mo ago
Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.
Mikhail_Edoshin 8mo ago
Here is a use case. I have a function that takes variable parameters, so there is no formal type control: int Foo(int a, ...); But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant: static inline FooVar1(char b, long c) { return Foo(FOO_VAR_1, b, c); } All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.
- 1718627440 8mo ago
  Then what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.
  - yxhuvud 8mo ago
    That is not an option - it may be layers on layers of them and force you to recreate half the library and force you to have to redo subsequent version updates in your code. Then a shim is the preferred solution. But anything that requires a C compiler for FFI is something that won't make anyone happy. Hence my claim that it really is something that needs fixing on the language or linker level.
    - 1718627440 8mo ago
      But FooVar1 isn't part of the library, that's the point. Sure, the library developer could choose to make it a part, but he explicitly choose to not make it a part of the library. Hence, it is also nothing that needs fixing, because it is already possible to make the interface boundary somewhere else, people just choose to do it this way. As far as the language and the linker is concerned FooVar1 is part of your code, not part of the library.
      - yxhuvud 8mo ago
        If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.
        1718627440 8mo ago
        The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging. It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality. EDIT: Concerning your earlier complaint, that you would need to > have to redo subsequent version updates in your code. , such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former. Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.

zabzonk 8mo ago

i think you replied to the wrong comment

yxhuvud 8mo ago

Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.

Mikhail_Edoshin 8mo ago

Here is a use case. I have a function that takes variable parameters, so there is no formal type control: int Foo(int a, ...); But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant: static inline FooVar1(char b, long c) { return Foo(FOO_VAR_1, b, c); } All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.

1718627440 8mo ago
Then what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.
- yxhuvud 8mo ago
  That is not an option - it may be layers on layers of them and force you to recreate half the library and force you to have to redo subsequent version updates in your code. Then a shim is the preferred solution. But anything that requires a C compiler for FFI is something that won't make anyone happy. Hence my claim that it really is something that needs fixing on the language or linker level.
  - 1718627440 8mo ago
    But FooVar1 isn't part of the library, that's the point. Sure, the library developer could choose to make it a part, but he explicitly choose to not make it a part of the library. Hence, it is also nothing that needs fixing, because it is already possible to make the interface boundary somewhere else, people just choose to do it this way. As far as the language and the linker is concerned FooVar1 is part of your code, not part of the library.
    - yxhuvud 8mo ago
      If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.
      - 1718627440 8mo ago
        The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging. It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality. EDIT: Concerning your earlier complaint, that you would need to > have to redo subsequent version updates in your code. , such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former. Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.