Any disadvantage if only using cpp files without separate header files?

Question

I have found some threads that explain why C++ separates .cpp and .h files (e.g. here). I'd be interested to know if it causes any problem if I don't separate them. I don't want to share the object files, so what's the benefit of the separation on a small project? If it just slows down the compilation time, it's not a big deal in my opinion. I want to re-implement a Java program in C++, so to me it seems much easier to keep a class in one file only. Example:

// Hello.cpp
#ifndef HELLO_20091218
#define HELLO_20091218

#include <iostream>
#include "Utils.cpp"

class Hello
{
public:
 void start()
 {
  std::cout << Utils::nrand(100) << "\n";
        // Utils and all other classes are written in a similar way
 }
};

#endif

There is a thing that troubles me. "Defining a member function inside the class asks the implementation to expand calls to it inline." So if I do like this, everything is marked inline implicitly. Will it cause a larger executable or any other disadvantages?

Answer 1

That's really two questions.

Right now, what you've shown above as "Hello.cpp" looks like a header, complete with an include guard. The compiler doesn't really care what name you give your header, but including a .cpp file will be confusing (at best) to anybody looking at your code. If you're compiling this on its own, the include guard (at least) should probably go -- while it doesn't cause a real problem, it's pointless and confusing at best.

Yes, member functions that you define inside the class definition are implicitly inline. That doesn't mean the compiler is required to generate inline code for them though. It's basically just a hint to the compiler, and most compilers decide on their own whether to generate inline code, based mostly on what the function contains, not where it's defined.

Answer 2

The purpose of a header file is to encapsulate specific functionality which an application regards as an API.

In many cases, the corresponding source files are in a single library file, or at least an independent package. Directly combining source code (as separate files) into a project is expedient and often helpful in development as opposed to building a library and linking that in.

That words such as package, library, and API are so heavily laden with alternate technical meanings attests to the importance developers have for such an arrangement.

If you think there is some future reuse for a class you've written, it wouldn't be bad practice to break in into separate .cpp and .h files so you can easily refer to it in another project. As for penalties in compilation speed, consider the long term benefits versus the cost. (And that compilers and hardware tend to get faster every year.)

Answer 3

In C and C++ the smallest unit of compilation is the file. If you just don't use header files and include everything in your "main" file, everytime you change something your whole program would have to be recompilled. For larger applications this can be a very good argument for separation of header and implementation. Also if another part of your application would live in another binary executable and you wan't to reuse classes you are safe with header files while you will get alot of overhead without them.

If you don't care about those things (You'll regret that.) there is no need in separate header files for you.

About the inlining: The compiler will inline a lot of functions (sometimes even whole classes, so to speak) anyway, even if you don't ask it to do that. Inlining is generally a benefit for performance. There are corner cases (large size of the executable can resolut in slower execution) but those are fairly unusual.

Answer 4

"When In Rome Do As The Romans Do"

You are tricked into thinking that you have a choice to use C++ just like Java. Although this is technically correct, you are breaking some very strong conventions that exist for a reason. You could just as easy start using new without calling delete because "it's not a big deal", or "your program is small" or "OS will reclaim all the memory after your program is closed", but that doesn't mean that you should do it. I agree that C++ is more complicated than Java and that this can be a real pain but this is something you'll have to deal with. It's what every C++ developer accepts sooner or later.