---
# CREATED BY ARCH LINUX USER

Hi everyone took a lot of time to understand a concept from this page that was not explained properly. Certain concepts where not explained properly so I am posting it here. I will be happy if my comment gets approved :) . Case 2 was written by AI but Case 1 is written by me. The explanation is a long one :-


## CASE 1 :- WHAT IF WE CHANGE THE ADD.CPP FILE BUT NOT THE ADD.H FILE

Lets say we have the following files :-

add.h

```
int add(int x, int y);
```

add.cpp

```
#include "add.h" 

int add(int x, int y)
{
    return x + y;
}
```


main.cpp

```
#include "add.h" 
#include <iostream>

int main()
{
    std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
    return 0;
}
```

What if add.cpp only contained :- 

add.cpp

```
int add(int x, int y)
{
    return x + y;
}
```

So what if we changed something in add.cpp but not in add.h ? For example

add.cpp

```
double add(int x, int y)
{
    return x + y;
}
```

main.cpp

```
#include "add.h" // Insert contents of add.h at this point.  Note use of double quotes here.
#include <iostream>

int main()
{
    std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
    return 0;
}
```


add.h

```
int add(int x, int y); // function declaration includes return type, name, parameters, and semicolon.  No function body!
```

Then look preprocessor will include add.h into main.cpp which will look like this :-

main.cpp

```
int add(int x, int y);
#include <iostream>

int main()
{
    std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
    return 0;
}
```

main.cpp , add.cpp will BE SUCESSFULLY COMPILED BY COMPILER INDIVIDUALLY but LINKER WILL GIVE ERROR BECAUSE IT WILL NOT BE ABLE TO FIND IMPLEMENTATION OF int add(int x, int y); WHICH WAS NEEDED IN FUNCTION CALL IN MAIN.CPP . WE ONLY HAVE THE IMPLEMENTATION OF double add(int x, int y); IN add.cpp. 

INSTEAD IF `#include "add.h"` WAS ALREADY PRESENT IN ADD.CPP THEN 

add.cpp

```
#include "add.h" // Insert contents of add.h at this point.  Note use of double quotes here.

double add(int x, int y)
{
    return x + y;
}
```

PREPROCESSOR WOULD CONVERT IT TO

add.cpp

```
int add(int x, int y);

double add(int x, int y)
{
    return x + y;
}
```

WHICH IS COMPILER ERROR IT WILL BE AN ADD.CPP COMPILE TIME ERROR. THIS IS ALSO NOT A VALID FUNCTION OVERLOADING ALSO BECAUSE IN FUNCTION OVERLOADING NAME OF THE FUNCTION SHOULD REMAIN SAME AND NUMBER OF PARAMETERS SHOULD BE  DIFFERENT. RETURN TYPE CANNOT BE USED AS A BASIS FOR FUNCTION OVERLOAD.

## CASE 2 :- WHAT IF WE CHANGE THE ADD.H FILE BUT NOT THE ADD.CPP FILE

Here is a concrete example of how including `add.h` in `add.cpp` catches a mistake instantly at compile time.

  

### 1. You update the header (`add.h`)

Imagine you decide that `add` should return a `double` instead of an `int`:

  

C++

```
// add.h
double add(int x, int y); // Changed return type to double

```

### 2. You forget to update the source file (`add.cpp`)

Because you included `add.h` in `add.cpp`, the compiler automatically checks your implementation against the new rule:

  

C++

```
// add.cpp
#include "add.h" 
/* 
WHICH WILL BE REPLACED TO 
double add(int x, int y);BY PREPROCESSOR
 */
 
// Oops! We forgot to change this 'int' to 'double'
int add(int x, int y) 
{
    return x + y;
}

```

### 3. The Compiler Error

The moment you try to compile `add.cpp`, the compiler reads the `#include "add.h"`, sees that `add` is supposed to return a `double`, and then immediately spots your `int add(...)` definition below it.

  

It stops and throws an error like this:

  

> **error:** conflicting return type for 'double add(int, int)'
> 
> **note:** previous declaration is 'double add(int, int)'
> 
>   

### Why this is helpful:

If you hadn't included `add.h` in `add.cpp`, the compiler would have compiled `add.cpp` successfully (treating it as an `int` function) and `main.cpp` successfully (treating it as a `double` function). That kind of silent mismatch can lead to unpredictable bugs or crashes at runtime.

  

By including the header, the compiler acts as an automated safety net, ensuring your declaration and definition always match.

The aim is to avoid linker error and intentionally give compiler error.
---