Usually in C, we have to tell the computer the type of data in variable declaration. E.g. in the following program, I want to print the sum of two floating point numbers X and Y.

  float X=5.2;
  float Y=5.1;
  float Z;


I had to tell the compiler the type of variable X.

  • Can't the compiler determine the type of X on its own?

Yes, it can if I do this:

#define X 5.2

I can now write my program without telling the compiler the type of X as:

#define X 5.2
  float Y=5.1;
  float Z;


So we see that C language has some kind of feature, using which it can determine the type of data on its own. In my case it determined that X is of type float.

  • Why do we have to mention the type of data, when we declare something in main()? Why can't the compiler determine the data type of a variable on its own in main() as it does in #define.
  • 14
    Actually those two programs are not equivalent, in that they may give slightly different outputs! 5.2 is a double, so the first program rounds the double literals to float precision, then adds them as floats, while the second rounds the double representation of 5.1 back to double and adds it to the double value 5.2 using double addition, then rounds the result of that calculation to float precision. Because the rounding occurs in different places, the result may dffer. This is just one example for the types of variables affecting the behavior of an otherwise identical program.
    – user7043
    Dec 6, 2014 at 11:09
  • 12
    When you do #define X 5.2, X is not a variable, but a constant, so it is literally replaced be preprocessor with 5.2 anywhere you mentioned X. You cannot reassign X.
    – scriptin
    Dec 6, 2014 at 11:19
  • 16
    Just as a note: this is a blessing and a curse. On one hand, you have to type a few characters when the compiler really could have done it for you (C++'s auto actually does what you want). On the other hand, if you think you know what your code is doing, and you actually typed something else, static typing like this will catch an error earlier, before it becomes a huge problem. Every language strikes a balance: static typing, type inferrence, dynamic typing. For some tasks, the extra typing is actually worth it. For others, its a waste.
    – Cort Ammon
    Dec 6, 2014 at 16:57
  • Learn Ocaml and/or Haskell.... you'll be happy about their type inference abilities. Jan 10, 2015 at 9:07

4 Answers 4


You are comparing variable declarations to #defines, which is incorrect. With a #define, you create a mapping between an identifier and a snippet of source code. The C preprocessor will then literally substitute any occurrences of that identifier with the provided snippet. Writing

#define FOO 40 + 2
int foos = FOO + FOO * FOO;

ends up being the same thing to the compiler as writing

int foos = 40 + 2 + 40 + 2 * 40 + 2;

Think of it as automated copy&paste.

Also, normal variables can be reassigned, while a macro created with #define can not (although you can re-#define it). The expression FOO = 7 would be a compiler error, since we can't assign to “rvalues”: 40 + 2 = 7 is illegal.

So, why do we need types at all? Some languages apparently get rid of types, this is especially common in scripting languages. However, they usually have something called “dynamic typing” where variables don't have fixed types, but values have. While this is far more flexible, it's also less performant. C likes performance, so it has a very simple and efficient concept of variables:

There's a stretch of memory called the “stack”. Each local variable corresponds to an area on the stack. Now the question is how many bytes long does this area have to be? In C, each type has a well-defined size which you can query via sizeof(type). The compiler needs to know the type of each variable so that it can reserve the correct amount of space on the stack.

Why don't constants created with #define need a type annotation? They are not stored on the stack. Instead, #define creates reusable snippets of source code in a slightly more maintainable manner than copy&paste. Literals in the source code such as "foo" or 42.87 are stored by the compiler either inline as special instructions, or in a separate data section of the resulting binary.

However, literals do have types. A string literal is a char *. 42 is an int but can also be used for shorter types (narrowing conversion). 42.8 would be a double. If you have a literal and want it to have a different type (e.g. to make 42.8 a float, or 42 an unsigned long int), then you can use suffixes – a letter after the literal that changes how the compiler treats that literal. In our case, we might say 42.8f or 42ul.

Some languages have static typing as in C, but the type annotations are optional. Examples are ML, Haskell, Scala, C#, C++11, and Go. How does that work? Magic? No, this is called “type inference”. In C# and Go, the compiler looks at the right hand side of an assignment, and deduces the type of that. This is fairly straightforward if the right hand side is a literal such as 42ul. Then it's obvious what the type of the variable should be. Other languages also have more complex algorithms that take into account how a variable is used. E.g. if you do x/2, then x can't be a string but must have some numeric type.

  • Thank you for explaining. The thing I understand is that when we declare the type of a variable(local or global), we are actually telling the compiler, how much space should it reserve for that variable in the stack. On the other hand in #define we are having a constant which is directly converted into binary code--however long it may be--and it is stored in the memory as it is.
    – user106313
    Dec 6, 2014 at 13:59
  • 2
    @user31782 - not quite. When you declare a variable the type tells the compiler what properties the variable has. One of those properties is size; other properties include how it represents values and what operations can be performed on those values. Dec 6, 2014 at 17:05
  • @PeteBecker Then how does the compiler know these other properties in #define X 5.2?
    – user106313
    Dec 6, 2014 at 17:10
  • 1
    That's because by passing the wrong type to printf you invoked undefined behavior. On my machine that snippet prints a different value each time, on Ideone it crashes after printing zero. Dec 6, 2014 at 19:49
  • 4
    @user31782 - "It seems like I can perform any operation on any data type" No. X*Y is not valid if X and Y are pointers, but it's okay if they're ints; *X isn't valid if X is an int, but it's okay if it's a pointer. Dec 6, 2014 at 19:50

X in the second example is never a float. It is called a macro, it replaces the defined macro value 'X' in the source with the value. A readable article on #define is here.

In the case of the supplied code, before compilation the preprocessor changes the code




and that is what gets compiled.

That means you can also replace those 'values' with code like

#define X sqrt(Y)

or even

#define X Y
  • 3
    It is just called a macro, not a variadic macro. A variadic macro is a macro that takes a variable number of arguments, e.g. #define FOO(...) { __VA_ARGS__ }.
    – hvd
    Dec 6, 2014 at 15:32
  • 2
    My bad, will fix :) Dec 6, 2014 at 19:15

The short answer is C needs types because of history / representing the hardware.

History: C was developed in the early 1970s and intended as a language for systems programming. Code is ideally fast and makes the best use of the capabilities of the hardware.

Inferring types at compile time would have been possible, but the already slow compile times would have increased (refer to XKCD's 'compiling' cartoon. This used to apply to 'hello world' for at least 10 years after C was published). Inferring types at runtime would not have fitted the aims of systems programming. Runtime inferrence requires additional run time library. C came long before the first PC. Which had 256 RAM. Not Gigabytes or Megabytes but Kilobytes.

In your example, if you omit the types



Then the compiler could have happily worked out that X & Y are floats and made Z the same. In fact, a modern compiler would also work out that X & Y aren't needed and just set Z to 10.3.

Assume that the calculation is embedded inside a function. The function writer might want to use their knowledge of the hardware, or the problem being solved.

Would a double be more appropriate than a float ? Takes more memory and is slower but the accuracy of the result would be higher.

Maybe the return value of the function could be int (or long) because the decimals were not important, although conversion from float to int is not without cost.

The return value could also be made double guaranteeing that float + float does not overflow.

All of these questions seem pointless for the vast majority of code written today, but were vital when C was produced.

  • 1
    this doesn't explain eg why type declarations weren't made optional, allowing programmer to pick either to declare them explicitly or rely on compiler to infer
    – gnat
    Jan 7, 2015 at 19:37
  • 1
    Indeed it doesn't @gnat. I have tweaked the text but there was no point in so doing at the time. The domain C was designed for actually wanted to decide to store 17 in 1 byte, or 2 bytes or 4 bytes or as a string or as 5 bits within a word.
    – itj
    Jan 9, 2015 at 19:25

C doesn't have type inference (thats what it is called when a compiler guesses the type of a variable for you) because it is old. It was developed in the early 1970's

Many newer languages have systems that allow you to use variables without specifying their type (ruby, javascript, python, etc.)

  • 12
    None of the languages you mentioned (Ruby, JS, Python) have type inference as a language feature, although implementations may use it to increase efficiency. Instead, they use dynamic typing where values have types, but variables or other expressions don't.
    – amon
    Dec 6, 2014 at 11:35
  • 2
    JS doesn't allow you to omit the type - it's just doesn't allow you to declare it whatsoever. It uses dynamic typing, where values have types (e.g. true is boolean), not variables (e.g. var x may contain value of any type). Also, type inference for such simple cases as those from question has been probably known a decade before C was released.
    – scriptin
    Dec 6, 2014 at 12:11
  • 2
    That doesn't make the statement false (in order to force something you must also allow it). Type inference existing doesn't change the fact that C's type system is a result of its historical context (as opposed to a specifically stated philosophical reasoning or technical limitation) Dec 6, 2014 at 13:22
  • 2
    Considering that ML - which is pretty much just as old as C - has type inference, "it's old" isn't a good explanation. The context in which C was used and developed (small machines that demanded a very small footprint for the compiler) seems more likely. No idea why you'd mention dynamic typing languages instead of just some examples of languages with type inference - Haskell, ML, heck C# has it - hardly an obscure feature any more.
    – Voo
    Dec 6, 2014 at 16:38
  • 2
    @BradS. Fortran is not a good example because the first letter of the variable name is a type declaration, unless you use implicit none in which case you must declare a type. Dec 7, 2014 at 3:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.