3

I would like to write code in .hpp without separation to .h and .cpp

  • I did it. I use .cpp only for static class-fields definitions

I would like not to write #include manually ...

  • I use forward delarations where it possible.
  • Every my .hpp file containt #pragma once.
  • But, when my project grows up to 40-50 classes i saw problem of include graph. There are some errors of definitions.

Image with include graph of my project model (like part of mvc) attached.
I used this app for graph generation (can work without MSVS!).

include graph

How include graph should look like? Like a tree?
How not to write includes manually, like in C# or Java?

Community
  • 1
  • 1
k06a
  • 17,755
  • 10
  • 70
  • 110

4 Answers4

11

Unfortunately you're possibly using the wrong language. There are some things that are just much in C++ easier when you separate the class definition from implementation. Even with forward declarations you'll probably still wind up with circular dependencies that can only be resolved by moving implementations into separate files.

If you want to write idiomatic Java, just write it in Java. If you want to use the C++ language unfortunately you'll have to work within its constraints.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • But it can be separated interface and implementation instead of definition and implementation and interfaces can be used instead of forward declarations. It is more Object-Oriented ... – k06a Oct 13 '11 at 13:18
  • @k06a, you don't have to choose one othe other. If interfaces are useful for your application — use them, but separate your classes into header and implementations in either case. – Don Reba Oct 13 '11 at 13:34
  • 5
    Long story short: Don't use C++ to write Java. – John Dibling Oct 13 '11 at 14:07
1

Let's assume you have a .hpp file per class, then, the include graph is similar to the class dependency graph. For sake of reusability, a class dependency graph should be acyclic (you can achieve this by using interfaces to "split" cycles). So, I guess the include graph should be acyclic too.

As for the #include clauses, I'm afraid you have to write them manually. But if your classes are small enough, this shouldn't be a problem (if your classes are so huge you can't figure out what include you need, you've got a design problem).

Daniele Pallastrelli
  • 2,430
  • 1
  • 21
  • 37
  • Soon i have 2-3 similar (with single interface) classes in single header file, today i have splitted them to different headers. – k06a Oct 13 '11 at 13:30
  • @k06a Having one class for file is a good choice. Besides helping with include dependencies, it's simpler to find a class if you use the class name as file name. – Daniele Pallastrelli Oct 13 '11 at 13:39
1

Just as a small note, splitting your classes into .cpp and .h files not only solves the circular dependency problem, but also might dramatically increase your compilation time.

If you're attempting to write header-only code, you would probably end up with a full rebuild of your project even if one small part of code gets changed.

Header-only code only makes sense if you're designing a template-based library, basically, because template should reside in headers. See boost template library, for example. And also to mention, real application using template libraries still have those .cpp files for their code and that's where the instantiated templates are actually "used".

M. Williams
  • 4,945
  • 2
  • 26
  • 27
  • Full rebuild of project is not hard for me. Project is not so huge. Mutlithreaded compilation can be used (4x or 8x speedup). – k06a Oct 13 '11 at 13:32
1

I highly suggest placing implementation into ".cpp" files and declarations or interface into header files, ".hpp".

When an inline function is changed in a header file, ALL source files that include the header file will be recompiled. When a function is changed in a source file, only the source file needs to be recompiled.

Get the code working correctly and robustly before creating inline functions.

Another suggestion is to make libraries (collection of object files) for source files that are grouped by a theme or are not compiled often (i.e. they work and don't change).

Don't worry about the quantity of files nor the length of the build process. Focus on completing the project correctly, robustly and under schedule. Adjust the build process as necessary. If there is a lot of time in the schedule are the code works correctly and is robust, then make changes. If changing the build process can speed up development time *significantly", then make the changes.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154