3

I'm wondering to code a C++ application with a header-only layout like the following:

// code3.h
#include <iostream>
class code3
{
public:
  void print()
  {
    std::cout << "hello " << std::endl;
  }
};

// code2.h
#include "code3.h"
class code2
{
public:
  void print()
  {
    code3 c;
    c.print();
  }
};

// code1.h
#include "code3.h"    
class code1
{
public:
  void print()
  {
    code3 c;
    c.print();
  }
};

// main.cpp
#include "code1.h"
#include "code2.h"

int main()
{
  code1 c1; 
  c1.print();

  code2 c2; 
  c2.print();
}

The only cpp file will be the main file. The rest of the code will be placed in header files.

I would like to know if there is some kind of performance problem with this approach. I know that defining the methods in the class declarations inlines them, but as it will be only one cpp file, the inline methods won't be duplicated. I just want to focus my question on the performance. I'm not talking about extensibility, legibility, maintenance or anything else. I want to know if I'm missing something with this approach that could generate a performance problem.

Thanks!

Mohsen Heydari
  • 7,256
  • 4
  • 31
  • 46
Alvaro
  • 37
  • 1
  • 5
  • Change one character anywhere and you gotta recompile everything. One of the reasons of using different translation units is to improve compilation times. – syam Sep 28 '13 at 10:52
  • Do you know what a translation unit is, and the benefits (and pitfalls) of having more than one ? – WhozCraig Sep 28 '13 at 10:53

2 Answers2

4

You will find that this becomes rather unpractical when your project has several hundred files (or more), and ALL of the code has to be recompiled EVERY time you change something.

In a small software project, there's little reason to have different source files, but there is no huge drawback of having more than one source file.

When the source starts to be more than a dozen files, compile time starts to increase. It's also much harder to isolate functional groups of code, which in turn affects the ease with which you can take one lump of code and use it in a different project - which is often a useful thing when working on code.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Ok, but what if you split the code of your application into multiple libraries? In that case you will have to recompile only the library that you are modifying, right? – Alvaro Sep 28 '13 at 12:10
  • Yes, but if it's a library, it's not a "header only" solution in the first place. There are "header only library", which is where a set of tempplate code and other source code is in a header, but it's not a true library in that case - it's called a library, but the compile-time isolation is lost (it may use namespaces instead, but that's not going to guarantee that a file can be compiled on its own, as such). – Mats Petersson Sep 28 '13 at 16:52
  • Why is having a "minimum number of cpp files" of any benefit whatsoever. Having a larger number of files will make the code clearer (because there is less code in each file to understand). It's like saying "if I stack my books vertically rather than horizontally, I don't need so may shelves in my bookshelf" - which may well be true, but there is very little benefit from doing that, and it makes it harder to get the books out. – Mats Petersson Sep 28 '13 at 17:58
  • Yes, it won't be header-only. And about the minimum number of files, it's just that. I don't want to discuss what is more maintainable. Only if this approach has any kind of performance penalty. – Alvaro Sep 28 '13 at 18:05
  • There are performance effects from having code inlined - which is affected by the translation units (source files), but this works in both directions. Lack of maintainability is definitely one of the reasons that kill projects, so I wouldn't discount it that quickly. Unless of course it's only you working on the project and you are only working on a very small project. – Mats Petersson Sep 28 '13 at 18:07
  • Yes, it's just an small toy project. I was just wondering what performance implications it would have. Ok, thanks for the feedback! – Alvaro Sep 28 '13 at 18:13
  • If you design your code well, the effect on performance would be very small - if you do a bad design, the performance may be quite bad in either solution... – Mats Petersson Sep 28 '13 at 18:17
  • There is a cognitive drawback to profusion of very short source files. Locality of reference isn't only for caches - it gives us, humans, advantages as well. The most obvious example would be the verbose, non-minimal repro cases in some SO questions: the minimalism isn't some asocial pedantry, it's there so that we won't have to spend hours trying to understand. Many people think that they should simply minimize their existing sources and dump them into a question. Not so: it makes sense to put everything into one still small file, instead of a few small files. Same applies to bigger projects. – Kuba hasn't forgotten Monica Aug 02 '18 at 00:16
  • @MatsPetersson just a quick question, hope you dont mind answering instead of having me to post this a new question. In this case, how can I recompile the files that are changed automatically? or I have to resort to some scripting to find all the cahnged files and then isssue the recompile command? – Sean W Dec 03 '20 at 15:44
4

Last time I asked this question, I got a TON of useful answers: http://www.daniweb.com/software-development/cpp/threads/423106/separate-headers-from-source

Basically I asked why I should separate my source from headers because I also used to hate having "extra" files and switching back and forth between the header and the source. I think the answers I got may be useful for you so I'm just going to leave that link above.

Brandon
  • 22,723
  • 11
  • 93
  • 186