#define directive

I am trying to use #define in program

found page Preprocessor Directives - C Programming
other.h

Code:

---

#define PI 3.1415

---

main.c

Code:

---

#include<stdio.h> 
#include "other.h"
int main()
{ 
  printf("%f",PI); 
 
  return 0;
}

---

'PI' undeclared (first use in this function)
printf("%f",PI);
^~

How to use #define directive ?

That looks fine. Is this really the code that you compiled? Is there anything that you left out or which isn't the same as what you compiled?

Quote:

---

Originally Posted by laserlight

That looks fine. Is this really the code that you compiled? Is there anything that you left out or which isn't the same as what you compiled?

---

This code compile

Code:

---

#include <stdio.h> 
#define PI 3.1415
main()
{ 
  printf("%f",PI); 
}

---

but I want to use #define pre processor directive in program

I tried in first program but It gives error so I think I can't use only #define directive in header file

The header file is really called "other.h", correct?

Tim S.

If you're using an IDE, you need to add other.h along with main.c to your project files for the linker to make it work. Or, you should add the search directory for other.h to your compilers' default search directories by going to compiler settings (just remember, don't remove any of the other directories the compiler is set to by default).

Quote:

---

Originally Posted by Zeus_

you need to add other.h along with main.c to your project files for the linker to make it work.

---

The linker doesn't see .h files. :)

I mean, you'd usually have an other.c file along with the other.h to contain the implementation details. So, when you include other.h that's added into project files, the correct linking occurs with other.c. Have I got it right? I'm probably just bad at explaining it. I'm actually pretty comfortable when I need to use multiple files and with my setup.

Quote:

---

Originally Posted by abhi143

I tried in first program but It gives error so I think I can't use only #define directive in header file

---

You can use #define in a header; it is commonly used to define named constants.

Basically, if you have a header "other.h" that consists entirely of this:

Code:

---

#define PI 3.1415

---

And a "main.c" that consists entirely of this:

Code:

---

#include <stdio.h>
#include "other.h"

int main(void)
{
    printf("%f", PI);
    return 0;
}

---

then after preprocessing for the directive #include "other.h" without preprocessing any other macro directives, the result would be equivalent to:

Code:

---

#include <stdio.h>
#define PI 3.1415

int main(void)
{
    printf("%f", PI);
    return 0;
}

---

So, if the latter works but the former doesn't, the problem doesn't lie with your code; it lies with your project layout or compiler options such that "other.h" exists and should be in the same filesystem location relative to "main.c" or within the include file search path.

Quote:

---

Originally Posted by Zeus_

I mean, you'd usually have an other.c file along with the other.h to contain the implementation details. So, when you include other.h that's added into project files, the correct linking occurs with other.c. Have I got it right?

---

Macro proprocessing happens before the translation units have been "compiled", i.e., the header files are preprocessed with the source file to form the translation unit, with the various macro replacements taking place. Therefore, the linker is not involved in macro preprocessing, but rather deals with linking the object files that are the output of the main compilation process (along with linking with library files).

The linker knows nothing about .h files.
The .c files are turned into .o (object) files.
The linker only deals with object files (and libraries of those).
The object files contain missing addresses that need to be "linked" to connect them to each other, to the library code, and to the process bootstrap code that actually calls main().
Even at that point it may not be fully "linked" since modern loaders can often move the code around to make it more secure. Not to mention connecting it up dynamically to so-called "dynamically linked libraries" where more than one process can actually be linked up to the same code in memory.

Then again, that's just the traditional view. I suppose there may be some fancy modern linkers that are much more intelligent. But I don't know anything about that. :p