4

I have a .cpp that's getting rather large, and for easy management I'd like to split it into a few files. However, there are numerous globals, and I'd like to avoid the upkeep of managing a bunch of extern declarations across different files. Is there a way to have multiple .cpp files act as a single file? In essence, I'd like a way to divide the code without the division being recognized by the compiler.

Andrew Tomazos
  • 66,139
  • 40
  • 186
  • 319
Cannoliopsida
  • 3,044
  • 5
  • 36
  • 61
  • 6
    This sounds like you need to refactor your design, not simply divide the source file up. – Oliver Charlesworth Jun 03 '12 at 21:36
  • Did you write this program using classes? If yes: Each class should be in a different file. If no: consider rewriting it using classes. – Drew Galbraith Jun 03 '12 at 21:37
  • 1
    It was written with classes, but there are tons of global variables holding image resources (it's a game). Would a better design have been to have a one data structure holding references to every image, passing that structure to every function, and indexing the proper image out? – Cannoliopsida Jun 03 '12 at 21:39
  • 1
    @Akroy what about making another class that contains all the global stuff of your application? – moooeeeep Jun 03 '12 at 21:49
  • Yeah, doing something to that effect (involving lots of restructuring). I realized that this problem is indicative of an overall need for redesign. Thanks everyone! – Cannoliopsida Jun 03 '12 at 21:52

3 Answers3

6

Is there a way to have multiple .cpp files act as a single file?

Yes. That is the definition of #include. When you #include a file, you make a textual substitution of the included file in place of the #include directive. Thus, multiple included files act together to form one translation unit.

In your case, chop the file into several bits. Do this exactly -- do not add or detract any lines of text. Do not add header guards or anything else. You may break your files at almost any convenient location. The limitations are: the break must not occur inside a comment, nor inside a string, and it must occur at the end of a logical line.

Name the newly-created partial files according to some convention. They are not fully-formed translation units, so don't name them *.cpp. They are not proper header files, so don't name them *.h. Rather, they are partially-complete translation units. Perhaps you could name them *.pcpp.

As for the basename, choose the original file name, with a sequentially-numbered suffix: MyProg01.pcpp, MyProg02.pcpp, etc.

Finally, replace your original file with a series of #include statements:

#include "MyProg01.pcpp"
#include "MyProg02.pcpp"
#include "MyProg03.pcpp"
Robᵩ
  • 163,533
  • 20
  • 239
  • 308
  • I admit that I don't care for this answer. Not sure why, exactly. It seems to strain C++ idiom, somehow. Do you actually write code like this? How does it work for you? Isn't it unmaintainable? – thb Jun 03 '12 at 21:56
  • 2
    No, I'd never write code like this. My code follows the typical CPP conventions related to what goes in a header and what goes in a CPP file. But OP didn't ask for the best practice. He asked how to implement the poor practice he had already chosen. – Robᵩ Jun 04 '12 at 14:31
5

Of course, you can always just #include the various CPP-files into one master file which is the one that the compiler sees. It's a very bad idea though, and you will eventually get into headaches far worse than refactoring the file properly.

harald
  • 5,976
  • 1
  • 24
  • 41
1

whilst you can declare the same set of globals in many cpp files, you will get a separate instance of each as the compiler compiles each file, which will then fail to link as they are combined.

The only answer is to put all your globals in their own file, then cut&paste them into a header file that contains extern declarations (this can easily be automated, but I find using the arrow keys to just paste 'extern' in front of them is quick and simple).

You could refactor everything, but often its not worth the effort (except when you need to change something for other reasons).

You could try splitting the files, and then using the compiler to tell you which globals are needed by each new file, and re-introducing just those directly into each file, keeping the true globals separately.

If you don't want to do this, just #include the cpp files.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
  • Do you have luck #including cpp files? Naturally the preprocessor will do it for you if you ask it to, but there seems something unnatural about this. The reason I ask is that, years ago, I used to do the equivalent of what you suggest in Fortran 77. It was a mess. I have always assumed that the reason it wasn't typically done that way in C++ was precisely to avoid the sort of mess I used to see in the old Fortran. – thb Jun 03 '12 at 21:55