Asked  7 Months ago    Answers:  5   Viewed   76 times

So I finished my first C++ programming assignment and received my grade. But according to the grading, I lost marks for including cpp files instead of compiling and linking them. I'm not too clear on what that means.

Taking a look back at my code, I chose not to create header files for my classes, but did everything in the cpp files (it seemed to work fine without header files...). I'm guessing that the grader meant that I wrote '#include "mycppfile.cpp";' in some of my files.

My reasoning for #include'ing the cpp files was: - Everything that was supposed to go into the header file was in my cpp file, so I pretended it was like a header file - In monkey-see-monkey do fashion, I saw that other header files were #include'd in the files, so I did the same for my cpp file.

So what exactly did I do wrong, and why is it bad?

 Answers

65

To the best of my knowledge, the C++ standard knows no difference between header files and source files. As far as the language is concerned, any text file with legal code is the same as any other. However, although not illegal, including source files into your program will pretty much eliminate any advantages you would've got from separating your source files in the first place.

Essentially, what #include does is tell the preprocessor to take the entire file you've specified, and copy it into your active file before the compiler gets its hands on it. So when you include all the source files in your project together, there is fundamentally no difference between what you've done, and just making one huge source file without any separation at all.

"Oh, that's no big deal. If it runs, it's fine," I hear you cry. And in a sense, you'd be correct. But right now you're dealing with a tiny tiny little program, and a nice and relatively unencumbered CPU to compile it for you. You won't always be so lucky.

If you ever delve into the realms of serious computer programming, you'll be seeing projects with line counts that can reach millions, rather than dozens. That's a lot of lines. And if you try to compile one of these on a modern desktop computer, it can take a matter of hours instead of seconds.

"Oh no! That sounds horrible! However can I prevent this dire fate?!" Unfortunately, there's not much you can do about that. If it takes hours to compile, it takes hours to compile. But that only really matters the first time -- once you've compiled it once, there's no reason to compile it again.

Unless you change something.

Now, if you had two million lines of code merged together into one giant behemoth, and need to do a simple bug fix such as, say, x = y + 1, that means you have to compile all two million lines again in order to test this. And if you find out that you meant to do a x = y - 1 instead, then again, two million lines of compile are waiting for you. That's many hours of time wasted that could be better spent doing anything else.

"But I hate being unproductive! If only there was some way to compile distinct parts of my codebase individually, and somehow link them together afterwards!" An excellent idea, in theory. But what if your program needs to know what's going on in a different file? It's impossible to completely separate your codebase unless you want to run a bunch of tiny tiny .exe files instead.

"But surely it must be possible! Programming sounds like pure torture otherwise! What if I found some way to separate interface from implementation? Say by taking just enough information from these distinct code segments to identify them to the rest of the program, and putting them in some sort of header file instead? And that way, I can use the #include preprocessor directive to bring in only the information necessary to compile!"

Hmm. You might be on to something there. Let me know how that works out for you.

Tuesday, June 1, 2021
 
hakre
answered 7 Months ago
50

Including <bits/stdc++.h> appears to be an increasingly common thing to see on Stack Overflow, perhaps something newly added to a national curriculum in the current academic year.

I imagine the advantages are vaguely given thus:

  • You only need write one #include line
  • You do not need to look up which standard header everything is in

Unfortunately, this is a lazy hack, naming a GCC internal header directly instead of individual standard headers like <string>, <iostream> and <vector>. It ruins portability and fosters terrible habits.

The disadvantages include:

  • It will probably only work on that compiler
  • You have no idea what it'll do when you use it, because its contents are not set by a standard
  • Even just upgrading your compiler to its own next version may break your program
  • Every single standard header must be parsed and compiled along with your source code, which is slow and results in a bulky executable under certain compilation settings

Don't do it!


More information:

  • #include <bits/stdc++.h> with visual studio does not compile
  • How does #include <bits/stdc++.h> work in C++?

Example of why Quora is bad:

  • Is it good practice to use #include <bits/stdc++.h> in programming contests instead of listing a lot of includes?
Tuesday, June 1, 2021
 
jsuggs
answered 7 Months ago
16

C and C++ have the concept of a "compilation unit", which is essentially "all the code in the file you tell me to compile plus all the files it includes".

The original pipeline for C compilation was to first run the "pre-processor" to read in all of the code, process the macros and defines etc, and output the resulting code into a single file (from memory, a .i file for intermediate)

foo.cpp

#include "foo1.h"
FOO {
    #include "foo2.h"
}

foo1.h

extern "C" int puts(const char*);
#define FOO int main()

foo2.h

puts("Hello, worldn");

Compile with g++ -Wall -E -o foo.i foo.cpp and g++ -Wall -o foo.exe foo.i

The foo.i file looks like this:

# 1 "foo.cpp"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 30 "/usr/include/stdc-predef.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/predefs.h" 1 3 4
# 31 "/usr/include/stdc-predef.h" 2 3 4
# 1 "<command-line>" 2
# 1 "foo.cpp"
# 1 "foo1.h" 1
extern "C" int puts(const char*);
# 2 "foo.cpp" 2

int main() {
# 1 "foo2.h" 1
 puts("Hello, world!n");
# 5 "foo.cpp" 2
}

This is a compilation unit. The process is simplified these days, the pre-processor being built in to the compiler itself, but the notion of a compilation unit still remains.

The problem with your code is that you are defining - not just declaring - IF_DEBUG_ENABLED in a header file, and thus potentially in multiple compilation units. When the linker tries to combine the compiled units into an executable, it's finding multiple instances of a variable with the same name. The linker has no way to tell that they were supposed to be the same thing.

To create a global variable or function visible between multiple compilation units (source files), you need a header declaration/prototype and a source-file definition/instance.

header

extern bool IF_DEBUG_ENABLED; // variable declaration.
extern void herp();           // function prototype, but
void herp();                  // the extern is optional for functions.

To be able to use either of these, you now need to back them up with a implementation.

source file

bool IF_DEBUG_ENABLED = true;

This is, assuming that you want it to be a run-time variable. Another option you have is to use a #define, just like the guard you were using:

constant.h

#ifndef CONSTANT_H // poor choice, there may be a CONSTANT_H somewhere else.
#define CONSTANT_H 1

...
#define IF_DEBUG_ENABLED // comment out to disable

#endif

source:

#if defined(IF_DEBUG_ENABLED)
   qDebug() << message;
#endif

This option doesn't allow you to change IF_DEBUG_ENABLED during run-time, the "qDebug() << message" code is only written to the executable if IF_DEBUG_ENABLED is defined at compile time.

Lastly, instead of using the #if ... #define ... #endif guard method, you can replace all three with a single line at the start of the file:

constant.h:

#pragma once  //<<-- compiler implements a guard for you.

#include <QString>

class Debug
{  
public:
    static void Log(QString Message);
};
Saturday, July 31, 2021
 
ar.gorgin
answered 4 Months ago
25

Each C file is a different translation unit. In other words, it is an entire separate program, syntactically complete and correct. Thus, each C file must compile independently of any other C file, and must contain every declaration for every identifier it uses, regardless of whether these declarations also appear in other C files. From the compiler point of view, each C file is a complete program by itself (albeit with unresolved references).

Header files are, by convention, files that contains declarations that must appear in a group of C files. Header files can be included by the preprocessor -- which is a simple textual copy-and-paste at the include point -- as a convenience to avoid manually duplicating declarations between the translation units.

Summing up: it is not redundant to include the same files in different C files -- it is formally required.

(Afterwards, you link object files, which are just smaller programs, into a larger final program. The larger program is roughly a summation of smaller subprograms, with all references resolved between them. Generally speaking, the linking phase does not know anything about the language structure of the original files that generated the resulting object file.)

Wednesday, August 11, 2021
 
Sam Adamsh
answered 4 Months ago
96

The most important difference is the fact, that if you use a field, and later need to change it to a property (say, to enforce some validation), then all libraries calling your code will need to be recompiled. It's true that you can compile the exact same code if the name stays the same - but the consumers of your code will still need to be recompiled. This is because the IL generated to get the value is different between a field and a property. If it already is a property, you can make a change without forcing consumers of your code to change.

This may or may not be an issue for you. But the property is almost the same amount of code, and is considered best practice. I would always go for the property.

Sunday, August 22, 2021
 
iammichael
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share