15

I tried looking this up and got mixed results using header files and such.

Basically I have multiple .cpp files with all my functions I made for use with binary trees, BST, linked lists, etc.

Instead of having to copy and paste functions as I need them, I want to just be able to do a:

#include <myBSTFunctions.h>

And be able to call and use my own functions.

What are the steps to accomplish this? Make a header file with all the function prototypes I used?

And where should I place the .cpp and header file with all the actually functions?

Is there a way I can call the directory of the functions file directly?

I.e., I'm more thinking of having it in the same folder with the main source .cpp file to share with some of my colleagues.

How can I accomplish this?

On Windows and the MinGW compiler.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Emrit
  • 303
  • 1
  • 3
  • 6
  • 3
    platform? toolchain? – pm100 Jul 23 '18 at 22:31
  • 5
    Helpful reading: [How does the compilation/linking process work?](https://stackoverflow.com/questions/6264249/how-does-the-compilation-linking-process-work). Exactly how this works differs from compiler tool chain to tool chain. For g++ it can be as simple as `g++ A.cpp B.cpp` – user4581301 Jul 23 '18 at 22:32
  • How will the compiler know where to find a.cpp? – Emrit Jul 23 '18 at 22:36
  • 3
    Also, reading a book on C++ might assist in understanding multi-file programs: [here are a few nice ones](https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list) – Carl Jul 23 '18 at 22:37
  • 3
    "How will the compiler know where to find a.cpp? " If it's not in the current working directory you have to tell the compiler where it is `g++ A.cpp ../../source/b/B.cpp` says look for A.cpp in the current folder and to find B.cpp, go back two folders and look in source/b. – user4581301 Jul 23 '18 at 22:45
  • Loads of duplicate questions must exist among the [762,341 C++ questions](https://stackoverflow.com/questions/tagged/c%2b%2b) and [378,428 C questions](https://stackoverflow.com/questions/tagged/c). – Peter Mortensen Apr 26 '22 at 12:25

4 Answers4

21

Declare functions in a header:

// File MyFunctions.h
int myFunction1(int, int);
int myFunction2(int, int);

Implement them in file MyFunctions.cpp:

// File MyFunctions.cpp
#include "MyFunctions.h"
int myFunction1(int a, int b){
    // Your code

int myFunction2(int a, int b){
    // Your code
}

Include the header in whatever file you want:

// OtherFile.cpp
#include "MyFunctions.h"
// Now you have access to the functions defined in MyFunctions.h in this file

I don’t know MinGW, but it should look something like:

g++ otherfile.cpp MyFunctions.cpp...
Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Diogo
  • 411
  • 1
  • 4
  • 7
  • thanks! I'm finally starting to realize why/how this works (i think). It feels like .h files are akin to prototyping functions. using them like this makes that clear, but thusfar i've only seen them used with classes, so it always seemed like just another piece in the magic, black box called "classes" – Ac Hybl Jan 16 '22 at 16:14
  • "miniGW" was most certainly a misspelling of [MinGW](https://en.wikipedia.org/wiki/MinGW). – Peter Mortensen Apr 07 '22 at 20:33
17

You seems to be missing some pretty basic concepts in how to build a program. I'm going to give you a very basic primer, but you will have to go and find more complete answers elsewhere to really understand what's going on and to get the specifics for your setup.

  1. You generally tell the compiler to compile each of your cpp files. When a cpp file has an #include statement, that basically copies and pastes the included file into your cpp file before compiling (this is done by the preprocessor). Each of these complete units (cpp file, with includes) processed by the compiler is called a translation unit. Each translation unit produces one object file.

  2. Object files contain compiled code, but they are often not complete. That is, they contain references to code that are not contained in them. Basically, they can say "now call this function, I don't know where it is or what it does, but you should call it".

  3. The linker is then used to link object files, perhaps together with libraries, into an executable (or a library). The linker's job is to "resolve" all of the references to external code in each object file by finding the relevant code in other object files and libraries.

  4. Libraries come in two flavours: shared libraries (.dlls in Windows) and static libraries. A static library is linked into the executable (or other library) by the linker, meaning you can then use the executable without the library (relevant library code becomes part of the executable). You can also link an executable/library against a shared library, in which case you'll need a copy of that shared library every time you run your executable -- the operating system will need to dynamically link your compiled code to the shared library before running it.

So, back to your question.

You have, broadly, three choices: compile then link all of your cpp files directly each time in a single project; compile useful reusable code into a static library, then link your project against it; or compile useful reusable code into a shared library, link your project against it, and make sure to ship the shared library with the result so it can be run.

Most projects of any reasonable size will combine at least two of these. Multiple cpp files will be part of the project code, which will be compiled as separate translation units and given to the linker. Most projects will also use some libraries (either that you write yourself, or that others have written) that are linked statically or dynamically as appropriate.

Unfortunately (imho) C++ as a language doesn't come with a single build system to organise all of this for your (more recent languages often do). There are several different compilers/linkers and many different build systems that can all do all of this. The specific steps you need to take, unfortunately, depend an awful lot on your choice of compiler and build system.

JMAA
  • 1,553
  • 11
  • 21
6

That is quite simple. As JMAA said, you should do some research to understand these concepts, but being practical, this is what you would do:

You'll define an functionsExample.cpp where you have to define all your functions and also an functionsExample.h where you'll declare your functions.

You'll have this as the functionsExample.cpp:

#include <iostream>
int example(int x, int y)
{
    return x + y;
}

Ans this as functionsExample.h:

#ifndef FUNCTIONSEXAMPLE_H
#define FUNCTIONSEXAMPLE_H

int example(int x, int y);

#endif

Then in the .cpp file you want to run the example function. Simply add:

#include "functionsExample.h"

But as I said, you should do some research about header guards, preprocessor directives and files organization to have a deeper knowledge about this. Some links I would recommend:

Header Files

Preprocessor Directives

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Caio Gomes
  • 562
  • 1
  • 8
  • 20
1

The easiest way to do this is to use a build tool. My personal preference is Meson, but CMake is more popular. There are others, but you can't go wrong with either of these. Both of these are cross-platform and support different toolchains. This means that as long as your code is standard C++ you can compile it just as easily using MinGW, Visual Studio, G++, or Clang without changing anything. They let you choose from the available toolchains on your platform. Each has a quick start tutorial on its web site.

The configuration file, which you write, specifies what program source files to use and what executables to build. The build chain that you use is selected in the configuration step and after that you can build your executables by running Make or Ninja (required by Meson and recommended for CMake). If you change your source, you only need to rerun Make or Ninja. Of course only the changed parts are rebuilt. Only the executables that are affected by your changes are relinked as well.

It may be educational to watch a few verbose builds to get familiar with the build process on your system.

PS: Traditionally, in #includes you use angle brackets (<>) for system headers and quotes ("") for your own. It has to do with where to look for them first.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Michael Surette
  • 703
  • 1
  • 4
  • 12