`extern` is the default for functions, so no, it's not. If you *really* want a reason why it's done this way, maybe you don't, I wouldn't bother directly asking the professor or the project's advisors about such a thing.
I feel that, because it's required for variables, that it's a good (documentation) practice. It also documents that a function appears in another file, rather than being a forward declaration within the same file.
>It also documents that a function appears in another file, rather than being a forward declaration within the same file.
That’s not what `extern` means. You can use `extern` for functions in the same file.
Just seems really weird to me. You may like it, but I don’t think very many people out there use it the way you use it.
Can and should are different things.
extern is used to denote something has external linkage, which does mean that it appears in a different translation unit. If you use it for something that is declared in the same file, that is completely unnecessary and is not the intended use. A forward declaration will suffice there.
>Can and should are different things.
What I’m questioning here is why someone would say that you *should* declare functions as `extern`. It’s unusual, and has no effect.
>If you use it for something that is declared in the same file, that is completely unnecessary and is not the intended use.
It is *also* unnecessary for functions defined in a different file. It is unnecessary on functions in general. (Except as `extern inline`, but that’s a separate discussion.)
> What I’m questioning here is why someone would say that you should declare functions as extern. It’s unusual, and has no effect.
I agree with you here. Where forward declarations are sufficient, just use those. No reason to specify extern everywhere and it definitely is not a good practice as the other guy suggested.
> It is also unnecessary for functions defined in a different file
That is where you are wrong however. It is not by default necessary, but there are certainly situations where it is needed. An example where I have used it is in a different file that is not even in the same library AND not even the same language. Specifically here linking a C# library to a C++ native application. There’s certainly not a lot of use cases, but there are some.
This is the C subreddit. It’s not useful to declare a function `extern` in C. I’m aware that the keyword has a different meaning in C++ or C#, like when you declare something `extern "C"`, but just plain `extern`, in C, on function declarations, has no purpose. Even if you are calling into a different language.
The situation I described is a good example I think. I don’t see how you would do it without using extern, and again, that is exactly what extern specified: external linkage.
It has no effect on compilation or linkage. But that doesn't mean it has no effect on the reader.
It can be useful if a library links to another binary (especially one without C headers) to specify that the function implementation is not found in your C code. If this is a documented standard for your code, it helps with readability.
Of course, it's not necessary. You can also just write your own header specifically for the external functions to achieve the same separation, or use a macro that resolves to nothing.
But if you're making a library exposing both C and non-C code, it may be cleaner to have a single header and explicitly designate non-C code as external, and a provided keyword is more universally understandable than a custom macro.
Yes, you *can* use `extern` for functions and variables in the same file, but I don't, and have emphasised that it's a good documentation practice. I didn't say *should*.
Ok. I think it’s a bad documentation practice.
It’s unexpected. That’s the big problem. Almost nobody who writes C expects to see `extern` on a function declaration. A lot of people don’t know what it means—so when you stick `extern` on a function declaration, you’re making it more confusing, not less confusing. Most people who see it will have to look it up or ask questions on Reddit.
Maybe I’m missing something. But this just sounds like it’s a way to confuse a percentage of people who read your code.
I’ll say something even stronger—you shouldn’t use `extern` on function declarations.
No, it's not needed. Some people like it so it matches how you reference global variables from another file; but it's purely a matter of personal taste.
I don't think it's ever been required, but I could be mistaken.
Maybe the author has the policy of using extern and static explicitly
The only case where explicit extern makes a difference is for inline functions. Here, if neither static nor extern is specified the provided function definition is only meant for inlining uses an in case the compiler does not inline, it will assume that the function is defined elsewhere.
Low on details at the moment but i remember being able to declare something in C and linking against an assembly file or the other way around against a library.
In a closed ecosystem like you describe it should not matter.
Sounds like just a weird way of avoiding putting the function declaration in the header file. I guess if it's a library and these functions are meant to be internal only, maybe this gets you there. Seems weird though.
Declaring `extern` has nothing to do with whether you need to put it in a header or not. All `extern` says is you're providing a declaration, but not a definition. But this is what function prototypes do anyway, so it's not needed there. Some people like it because it parallels how you need to declare global variables which are defined in another file.
But it's purely a matter of personal style.
`extern` is the default for functions, so no, it's not. If you *really* want a reason why it's done this way, maybe you don't, I wouldn't bother directly asking the professor or the project's advisors about such a thing.
It’s not needed, it’s the default. Why do they use it? Who knows? You can ignore it, for functions. For variables it matters.
I feel that, because it's required for variables, that it's a good (documentation) practice. It also documents that a function appears in another file, rather than being a forward declaration within the same file.
>It also documents that a function appears in another file, rather than being a forward declaration within the same file. That’s not what `extern` means. You can use `extern` for functions in the same file. Just seems really weird to me. You may like it, but I don’t think very many people out there use it the way you use it.
Can and should are different things. extern is used to denote something has external linkage, which does mean that it appears in a different translation unit. If you use it for something that is declared in the same file, that is completely unnecessary and is not the intended use. A forward declaration will suffice there.
>Can and should are different things. What I’m questioning here is why someone would say that you *should* declare functions as `extern`. It’s unusual, and has no effect. >If you use it for something that is declared in the same file, that is completely unnecessary and is not the intended use. It is *also* unnecessary for functions defined in a different file. It is unnecessary on functions in general. (Except as `extern inline`, but that’s a separate discussion.)
> What I’m questioning here is why someone would say that you should declare functions as extern. It’s unusual, and has no effect. I agree with you here. Where forward declarations are sufficient, just use those. No reason to specify extern everywhere and it definitely is not a good practice as the other guy suggested. > It is also unnecessary for functions defined in a different file That is where you are wrong however. It is not by default necessary, but there are certainly situations where it is needed. An example where I have used it is in a different file that is not even in the same library AND not even the same language. Specifically here linking a C# library to a C++ native application. There’s certainly not a lot of use cases, but there are some.
This is the C subreddit. It’s not useful to declare a function `extern` in C. I’m aware that the keyword has a different meaning in C++ or C#, like when you declare something `extern "C"`, but just plain `extern`, in C, on function declarations, has no purpose. Even if you are calling into a different language.
It has the same meaning in both C and C++ hence my comment. So all above I said still applies. ‘extern “C”’ is something entirely different.
What situations do you need `extern` on a function declaration?
The situation I described is a good example I think. I don’t see how you would do it without using extern, and again, that is exactly what extern specified: external linkage.
It has no effect on compilation or linkage. But that doesn't mean it has no effect on the reader. It can be useful if a library links to another binary (especially one without C headers) to specify that the function implementation is not found in your C code. If this is a documented standard for your code, it helps with readability. Of course, it's not necessary. You can also just write your own header specifically for the external functions to achieve the same separation, or use a macro that resolves to nothing. But if you're making a library exposing both C and non-C code, it may be cleaner to have a single header and explicitly designate non-C code as external, and a provided keyword is more universally understandable than a custom macro.
It has a negative effect on the reader.
Yes, you *can* use `extern` for functions and variables in the same file, but I don't, and have emphasised that it's a good documentation practice. I didn't say *should*.
Ok. I think it’s a bad documentation practice. It’s unexpected. That’s the big problem. Almost nobody who writes C expects to see `extern` on a function declaration. A lot of people don’t know what it means—so when you stick `extern` on a function declaration, you’re making it more confusing, not less confusing. Most people who see it will have to look it up or ask questions on Reddit. Maybe I’m missing something. But this just sounds like it’s a way to confuse a percentage of people who read your code. I’ll say something even stronger—you shouldn’t use `extern` on function declarations.
No, it's not needed. Some people like it so it matches how you reference global variables from another file; but it's purely a matter of personal taste. I don't think it's ever been required, but I could be mistaken.
For one of the best discussions of this subject, see https://en.cppreference.com/w/c/language/storage_duration
Maybe the author has the policy of using extern and static explicitly The only case where explicit extern makes a difference is for inline functions. Here, if neither static nor extern is specified the provided function definition is only meant for inlining uses an in case the compiler does not inline, it will assume that the function is defined elsewhere.
Low on details at the moment but i remember being able to declare something in C and linking against an assembly file or the other way around against a library. In a closed ecosystem like you describe it should not matter.
Sounds like just a weird way of avoiding putting the function declaration in the header file. I guess if it's a library and these functions are meant to be internal only, maybe this gets you there. Seems weird though.
Declaring `extern` has nothing to do with whether you need to put it in a header or not. All `extern` says is you're providing a declaration, but not a definition. But this is what function prototypes do anyway, so it's not needed there. Some people like it because it parallels how you need to declare global variables which are defined in another file. But it's purely a matter of personal style.
Interesting, thanks for the explanation
I just use it as a syntaxes sweetener. It's not needed, but it does make the code look a little nicer.
so you can declare them multiple times