   typedef and #define
  What is the difference between these two.typedef unsigned int UINT#define UINT unsigned int 
  typedef defines a ''type'' for later use#define is basicaly a global find and replace when used like that ;  Well, there is one main difference between the two to the best of my knowledge. Mainly, when you #define something, say #define PI 3.14, wherever you put PI in your program, it gets replaced by 3.14. For example:#define PI 3.14int i = PI;The compiler interpretes the statement as:int i = 3.14;typedef is something where you are actually defining a new type, so the compiler will define it in its symbol table and act accordingly when you use it. So in your example if you put:typedef unsigned int UINT;Your compiler will see UINT and treat it as a defined type that happens to be the same as an unsigned int but won''t replace it in your code the way that it would if you used a #define statment.If you put, say:#define UINT unsigned intUINT foo = 3.14;The compiler will interpret it as:unsigned int foo = 3.14;For your example, you will get the same results either way. This is a good question though, I''m just a newbie so I''d like to know more about typedef if at all possible.The only other thing I can say is that #define is a preprocessor directive, which means that before anything gets compiled, it will replace all occurences of the symbol with whatever it is defined as. And I am pretty sure that the typedef actually defines a new type that would get put in the symbol table and interpreted on compile time. Try to #define a function pointer based on this: typedef void (*FUNCTION_CALLBACK)(int);Z'' ;quote:Original post by ikkah  #define is pre-processor stuff and is concidered as evul. #defines don''t follow the scope rules or much of any other rules, that example of yours just replaces all UINTs with unsigned int. That is, if you wrote somewhere FLUINT (an integer value with a flu), it would be sent to the compiler as FLunsigned int. Typedefs or type definitions are better, you should use them.   [edited by - ikkah on February 19, 2004 3:05:59 PM]No, FLUINT would come out of the preprocessor as FLUINT.Typedefs are generally better, but I have encountered this situation:My common.htypedef unsigned int u32;  Another library''s common header:typedef unsigned long u32;  I had to use the other library''s header in my application (it got included somewhere along the line by its main header) and the result was a very hard to track bug. The reason is that 1) two typedefs to the same thing, I think it ignores one of them, 2) even after adding "typedef guards" like #ifndef _DEFINED_U32 ... there were still linker errors along the lines of "unresolved external other_library_function (u32, u32)" when there shouldn''t have been. To make a long story short, the function was exported as "u32=unsigned long" but being called as "u32=unsigned int". In the end we replaced the other_library_function declaration from u32 to unsigned ints.If both headers had used #define, there would NOT have been this problem. The compiler would have implicitly converted int to long or vice versa. But with typedefs, it''s a lot more strict. In this case, int != long. So watch out for that if it ever happens to you.(I know that namespaces would have solved this problem as well, but the other library did not use namespaces so it would have been a bitch) ;  // An ''angle'' variable for angle between 2 vectorstypedef Kurt float;Kurt Angle;;  Adding to why FLUINT remains FLUINT:  The preprocessor does replace text strings in the file with new text strings, based on #define directives, but it isn''t just a simple search and replace.  It looks for matching tokens  , not just matching substrings.  FLUINT is a single token.  It isn''t broken down further.  It doesn''t have whitespace, or parentheses, or anything else that define how tokens are separarted, between the FL and the UINT part.  Thus, when the preprocessor is trying to replace all "UINT"s with "unsigned int", it compares "UINT" to the token "FLUINT", and they''re not equal, so it moves on.  Just a bit of clarification, there.As for which is better, I would agree with most contemporary experts that typedef is better overall  .  In most cases, I''m sure the errors that occur because of conflicting typedefs are much easier to track down, compared to cases where #defines conflict.  Some cases may be backwards, but overall, typedefs are more capable of helping resolve bugs than #defines are, since the compiler actually has a bit more information about the situation, and can help you out. ;  Deep down, both are text replacement in C++.  However, the #define is done at the preprocessor stage (before the compiler gets to it) and the typedef is done by the compiler when trying to resolve a variable''s type.The one benefit to a typedef over #define that I can see is that you get scoping rules (i.e. a typedef can be private to a namespace/class/function).Sometimes I wish typedef actually defined a truly new type, but it does not:typedef unsigned int Size;Size s = 55;unsigned int i = s; // no problem for C++    [ Little Devils Inc. ] ;  I mainly use #defines for decalring default parameters that need to be known across files... For example: if the m_PowerUp == -1, then no power up is activated.  So I #define NO_POWERUP -1  then where I set the default in the initializer list  Construct::Construct() : m_PowerUp(NO_POWERUP).  This way, in other files I can just do: if(m_PowerUp == NO_POWERUP) { blah blah }Could just as easily hardcode the -1 in there, BUT, if ya ever wanna change it, depending on where ya use it, you could end up changing alot of files, and probably forgetting to change some of them.I never use #define to try to define my own variable types.;  Erm, sorry I take it back.  There is one other somewhat major difference between typedef and #define...typedef int* T_PINT;T_PINT p1, p2;  // p1 and p2 are integer pointers#define D_PINT int*D_PINT p3, p4;  // p1 is a int*, p4 is a int!!!typedef is preferred in almost all circumstances in my opinion.  [ Little Devils Inc. ] ;  Templated typedefs - once they make it into the language - will define new types. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor)