0

I'm working with functions. Is it good practice, that I write the function in another .cpp file, and I include it in the main one? Like this : #include "lehel.cpp".

Is this ok, or should I write the functions directly in the main.cpp file?

Shoe
  • 74,840
  • 36
  • 166
  • 272

4 Answers4

4

The established practice is putting function declarations of reusable functions in a .h or .hpp file and including that file where they're needed.

foo.cpp

int foo()
{
     return 42;
}

foo.hpp

#ifndef FOO_HPP // include guards
#define FOO_HPP

int foo();

#endif // FOO_HPP

main.cpp

#include "foo.hpp"

int main()
{
     return foo();
}

Including .cpp files is only sometimes used to split template definitions from declarations, but even this use is controversial, as there are counter-schemes of creating pairs (foo_impl.hpp and foo.hpp) or (foo.hpp and foo_fwd.hpp).

krzaq
  • 16,240
  • 4
  • 46
  • 61
  • So it's better if I declare the function in the main.cpp file. I'm a beginner :) – Balazs Lehel Sep 26 '16 at 19:48
  • I suggest you just create a header file instead of declaring it right within main. – krzaq Sep 26 '16 at 19:50
  • The beauty of `#pragma once` is if it's not supported the compiler is allowed to silently discard it, leaving you with no idea you have no include guards. Comic hi-jinks ensue. It also has some problems with symlinks and network mounts, other than that it's just peachy. Make sure your compiler supports the extension and that you won't be porting to other compilers and keep your build system simple and local and you're good to go. – user4581301 Sep 26 '16 at 20:03
  • You're right. Edited it out. – krzaq Sep 26 '16 at 20:06
4

A good practice is to separate functionality into separate Software Units so they can be reused and so that a change to one unit has little effect on other units.

If lehel.cpp is included by main, this means that any changes in lehel.cpp will force a compilation of main. However, if lehel.cpp is compiled separately and linked in, then a change to lehel.cpp does not force main to be recompiled; only linked together.

IMHO, header files should contain information on how to use the functions. The source files should contain the implementations of the functions. The functions in a source file should be related by a theme. Also, keeping the size of the source files small will reduce the quantity of injected defects.

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

Header files (.h) are designed to provide the information that will be needed in multiple files. Things like class declarations, function prototypes, and enumerations typically go in header files. In a word, "definitions".

Code files (.cpp) are designed to provide the implementation information that only needs to be known in one file. In general, function bodies, and internal variables that should/will never be accessed by other modules, are what belong in .cpp files. In a word, "implementations".

The simplest question to ask yourself to determine what belongs where is "if I change this, will I have to change code in other files to make things compile again?" If the answer is "yes" it probably belongs in the header file; if the answer is "no" it probably belongs in the code file.

https://stackoverflow.com/a/1945866/3323444

To answer your question, As a programmer it will be a bad practice to add a function when cpp has given you header files to include.

Community
  • 1
  • 1
krishnakant
  • 355
  • 1
  • 4
  • 17
0

Usually it is not done (and headers are used). However, there is a technique called "amalgamation", which means including all (or bunch of) .cpp files into a single main .cpp file and building it as a single unit.

The reasons why it might be sometimes done are:

  • sometimes actually faster compilation times of the "amalgamated" big unit compared to building all files separately (one reason might be for example that the headers are read only once instead for each .cpp file separately)
  • better optimization opportunities - the compiler sees all the source code as a whole, so it can make better optimization decisions across amalgamated .cpp files (which might not be possible if each file is compiled separately)

I once used that to improve compilation times of a bigger project - basically created multiple (8) basic source files, which each included part of the .cpp files and then were build in parallel. On full rebuild, the project built about 40% faster.

However, as mentioned, change of a single file of course causes rebuild of that composed unit, which can be a disadvantage during continuous development.

EmDroid
  • 5,918
  • 18
  • 18