you can access it using extern from anywhere:
reply // a.c
int f( int x ) {
return x + 1;
}
// b.c
extern int f(int x );
int main() {
int y = f(41);
}
"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".
replyJust because you can use the information you have to call a given function, doesn't mean you aren't violating an interface.
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.
replyBoth points are related and matter.
replyFor 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.
Then why not define "something" as static, which makes the compiler and linker guarantee that you can't do it?
replyWhat if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common.
replyI don't see what you're getting at with respect to writing bindings.
replyThe 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.
i think you replied to the wrong comment
reply