| ▲ | yxhuvud 9 hours ago |
| "static inline", the best way of getting people doing bindings in other languages to dislike your library (macros are just as bad, FWIW). I really wish someone on the C language/compiler/linker level took a real look at the problem and actually tried to solve it in a way that isn't a pain to deal with for people that integrate with the code. |
|
| ▲ | wahern 3 hours ago | parent | next [-] |
| > I really wish someone on the C language/compiler/linker level took a real look at the problem and actually tried to solve it in a way that isn't a pain to deal with for people that integrate with the code. It exists as "inline" and "extern inline".[1] Few people make use of them, though, partly because the semantics standardized by C99 were the complete opposite of the GCC extensions at the time, so for years people were warned to avoid them; and partly because linkage matters are a kind of black magic people avoid whenever possible--"static inline" neatly avoids needing to think about it. [1] See C23 6.7.5 at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#p... |
|
| ▲ | LtWorf 9 hours ago | parent | prev [-] |
| If it's not in the .h file it's supposed to be a private function. |
| |
| ▲ | zabzonk 8 hours ago | parent [-] | | you can access it using extern from anywhere: // a.c
int f( int x ) {
return x + 1;
}
// b.c
extern int f(int x );
int main() {
int y = f(41);
}
but if f() had been defined as static, you couldn't do this. | | |
| ▲ | bigfishrunning 7 hours ago | parent | next [-] | | "private function" doesn't mean "you can't know about this", it means "you shouldn't rely on this as a stable interface to my code". Just because you can use the information you have to call a given function, doesn't mean you aren't violating an interface. | | |
| ▲ | zabzonk 7 hours ago | parent [-] | | my point was that f() had been defined static then you can't access it from outside the translation unit it is defined in - in other words, it is "private". i'm afraid i'm unclear what your point is. | | |
| ▲ | Nevermark an hour ago | parent [-] | | Both points are related and matter. For most purposes, not being able to access something, and being able to access something not officially in an interface, where doing so introduces an unpredictable breaking dependency, the practical result is the same: You can't (actually/sensibly) do it. | | |
| ▲ | zabzonk an hour ago | parent [-] | | Then why not define "something" as static, which makes the compiler and linker guarantee that you can't do it? | | |
| ▲ | bigfishrunning an hour ago | parent [-] | | What if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common. |
|
|
|
| |
| ▲ | jlarocco 5 hours ago | parent | prev [-] | | 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. | | |
|
|
