How to declare source files in c

First of all, congrats on this really easy to read and understand article.

I have looked at the other comment and I didn't see anyone mention the extension of the source and header files. If I recall correctly, you can have, different extensions specifically for C++ files whereas `.c` and `.h` files can be compiled as C or C++.

The extension issue gets complicated, because to my understanding c files can be compiled with C++ compilers, but may be compiled with a "C subset" of C++.

To be honest, I don't know all the inside baseball around this, and I think I'd have to figure it out before I wrote about it.

I still do use .hpp to distinguish from C headers .h since I make wide use of both. I will include certain C header files into my C++ projects if they are things like macros or array embeds

Good work! Good article for what it intended. I think that given C++20, the article can be expanded to cover header-less programming: modules.
Sign in· View Thread

Can't we just say that the header files contain declarations while the source files have the definitions ?
Sign in· View Thread

Yes, that's what you could say, but I've found mnemonically it's easy to mix up those terms, and also leaving it at that doesn't really explain what they are, so it's not a route I would have taken for this article. That said, I *did* basically write this for a friend of mine, so I'm meeting someone where they are at in particular. I did try to make it general enough that others could find it useful though.

You can read in The C++ Programming Language Fourth Edition by Bjarne Stroustrup:

Declarations
Before a name (identifier) can be used in a C++ program it must be declared.

Definitions
There must always be exactly one definition for each name in a C++ program.

A definition is a declaration that supplies all that is needed in a program for the use of an entity.

A different terminology deems declarations part of an interface and definitions part of an implementation.

• A class definition specifies members and usually appears in a header file. A class declaration is just a forward declaration.
• When a header contains an inline function or data, it also provides a definition.

News to me! I'll defer to you on the terminology, as you seem more formally trained than I am in this. My vocabulary is all over the place. Thanks!

No formal training, just having to frequently read cppreference.com[^] while developing my static analysis tool.

Well you could have fooled me. In any case, you've clearly spent more time with the standard than I have.

Nice article, very clearly explained. I too would like to see a follow up to include Greg's suggestions.
Sign in· View Thread

Nice! Another advantage of avoiding implementation in the headers is that the CPP files generate object files that later linked into an EXE. If the CPP never changes, the object file does not need to be recompiled, thus saving on compilation time. This is not the case with the header only code. This is one of the headaches of the "boost library" code - the compilation time can be very long if the project does not utilize "precompiled headers".

Sign in· View Thread

Very true. I used to judge the quality of the C++ coder by how long their code took to compile. Generally, the longer, the better, because it means the developer was whipping the compiler like a rented mule, which is basically the idea with C++ - do everything you can at compile time so you don't have to at runtime.

Well this article is for beginners, so I do agree with you, but I don't think the readers here will have to worry about compile times - at least for their own code - for some time.

You make a very good point for large software projects. Even though static const class data can often be defined in a header, it should be defined in the .cpp if it is likely to change, as this avoids the need to recompile all transitive users of the header if it changes. This is just one way to speed up compiles, along with forward declarations, no unnecessary #include , and so on. John Lakos wrote an entire book [^] on this topic, which is now being expanded.

Nice explanation. Now we just need the teachers out there to point their students to it.
Sign in· View Thread

clear and important info, thanx
Sign in· View Thread

• external linkage vs. internal linkage
• use of extern in headers
• use of inline in headers (=multiple identical definitions are OK; no longer a compiler hint)
• use of static in source files (to ensure that functions and data at file scope remain private)

EDIT: A good summary of the keywords listed above can be found here[^].

I may do that as a second article at some point. Because this is such a beginner article, I wanted to keep anything intimidating out of it, and frankly, linkage still frustrates even me sometimes.

Greg Utas, you got me stewing on the nature of the follow up to this article. It will focus on using multiple source files rather than exploring them in the context of headers. Whereas in this article, multiple source files was kind of a minor point, there it will be the focus, and instead of worrying about things like headers, you'll see me cover these things.

One that scares me is all the different linkage nonsense I'd have to cover to really give the topic what it deserves without overwhelming the reader (or myself!) trying to explain it all.

There's also the issue of scope which, the intended audience of this article isn't entirely clear on OOP scoping yet. He knows variables are local to functions, but public and private confuse him, and static class members. I've been trying to explain it to him thus far over the phone. You can imagine how that's going.

So I might cover that first, before I get into this. I need to reflect. Also, thanks for the link. I should brush up myself before I try to write on this topic.

I'm a little confused by your use of "static". I've always understood it as specifying that the data or function was implemented at the class level (no object required) which also means that its lifetime is the same as the class's lifetime (typically the same as the application). Static data and functions can be public or private (or protected), there's nothing inherently private about static data or functions (although putting static data and functions in a source file instead of a header would effectively make them private to that file, but the same thing would apply to non-static data and functions).

Am I missing something?

You're quite right about static as it's used in a class. But outside a class, it works differently.

Maybe you've seen static used inside a function. A static local variable is initialized to a default during startup and preserves its most recent value across invocations of the function. In a sense, it's a global variable that can only be accessed within the function.

At file scope (outside a function) in a .cpp, tagging data or a function static ensures that it will remain private to the .cpp. If it isn't tagged static , nothing would prevent someone from declaring the data or function extern in a header in order to gain access to it. It's a subtle point, but using static in this case makes the design clear and precludes naughtiness in software being developed by a large team.

General News Suggestion Question Bug Answer Joke Praise Rant Admin

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

• Best Article of September 2022 : First Prize