1

Well, I'm getting in C++ universe and this doubt came over.

It's too boring to have 2 files for each meaning-unit I choose to include in my program. I know I can have multiple classes in the same (pair of) archive(s), however I would like to clarify if really there's no way to write just one file, instead of a .h and a .cpp ones.

I found some other answers (like this, that and that other) there are actually pretty explicative, but a quite older too. So hopping the language have got some improvement I came to ask:

Is there some compilation option, any another alternative extension, or whatever, that allows me to write just one file?

I appreciate it!

artu-hnrq
  • 1,343
  • 1
  • 8
  • 30
  • No, there is no proper way (yet) - modules. They found more important things to add to the language, rather than fix obsolete and quite terrible technology - preprocessor. – Slava Nov 21 '19 at 20:03
  • it is not required, you can put everything in single `.h` or single `.cpp` but it is just inconvenient – Iłya Bursov Nov 21 '19 at 20:03

2 Answers2

2

Okay, you need to understand what is going on. This isn't Java.

The .h file is the definition of your class. It's just an include file that can be used other places so those other places understand your class. Now, you CAN actually do the constructor inline, like this:

public:
     Foo() { ... your code here ... }

This is perfectly legal. But the problem with this is simple. Everywhere you hit this constructor, the compiler has to insert that code inline. This leads to lots of the same code everywhere you create a new Foo.

If you put the code in your .cpp file, and then compile it, you get a .o file. That .o file includes a single copy of your constructor, and that's what gets called everywhere you create a Foo.

So separating the definition from the code results in smaller programs. That's less important nowadays than it used to be.

This is the nature of C++, and you should accept it.

The .h is an include file, used in other places. The .cpp is the implementation. It's not really onerous, once you grow accustomed.

Joseph Larson
  • 8,530
  • 1
  • 19
  • 36
  • 3
    *Everywhere you hit this constructor, the compiler has to insert that code inline.* Can you back that up? `inline` does't actually mean inline the code, it means ignore duplicate definitions. – NathanOliver Nov 21 '19 at 20:19
  • 1
    I thought about being more precise but didn't want to make the answer more verbose. This is new programmer to C++, and I didn't want to add too much at once. Yes, you'll probably get one copy per .o file. That's true. But that could still be a lot of copies. – Joseph Larson Nov 21 '19 at 20:22
  • 2
    While the .o files will have a copy, the final executable won't have those copies as the linker will "merge" them into one. – NathanOliver Nov 21 '19 at 20:26
1

You have to understand that C++ is a compiled language. When you compile a library, for example, the library contains machine-specific code. If you want to write a program that uses that library, your program has to be able to see function and class definitions to properly link that library. On the other hand, it is absolutely possible to write your entire program in header files -- indeed, the term header-only library exists to describe libraries that have no pre-compiled machine code. That means the responsibility of compiling it falls to you. You'll likely have longer compile times, and because of this, very large libraries are almost exclusively pre-compiled into binaries that are platform-specific (in the absence of a set of binaries for you machine, you must compile from source and link against the result). In theory, one could rewrite the C++ spec in such a way that only one file was necessary, but then those files would need to be present within any project that incorporates that library. For very large libraries, this can be a pain -- why include the full source of some engine when you could include just the definitions necessary to link into the binaries? This provides the added advantage of obfuscating the algorithms and implementation details from the client program. C++ is not an interpreted programming language -- it's important to think about it from the compiler's perspective.

Joshua Hyatt
  • 1,300
  • 2
  • 11
  • 22