What exactly is a macro?
I know this probably sounds like a really dumb question. I've worked with MS Access, and from that I thought that macros were just shortcuts for little tasks that would be used often (I never really used them actually, 'cos apparently they're not totally compatable). Anyway, I've come across the word 'macro' quite a bit recently, and I'd like to know if anyone could explain it a little more in depth for me. What are they used for, and should I try to use them when I program games?
What is the difference between a macro and a function? I've tried to find 'macro' in the GameDev dictionary, alas, that was not to be...
[edited by - maccaroo on April 12, 2002 5:06:12 AM]
In the most general sense a macro is what you describe it as - a shortcut for often used tasks - where tasks are often combinations or sequences of commands. So rather than perform the same thing over and over again, it''s easier to write a macro to invoke once and be done with it. Macros are application and language specific. Some applications don''t provide them, some languages don''t provide them either. Whether or not you should use them depends on the language you want to use. If you intend to use C or C++ macros have their place - but they can also produce difficult to debug code because - since they''re not functions, no type checking is done on their parameters. One way to think about macros in C and C++ is as substitutions - because that''s what they are. The compiler substitutes the macro for what ever commands you have defined it to represent. If you''re not going to use C or C++, I wouldn''t worry about them.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
I am planning on using C/C++. At the moment I''m going through a Win32 tut, and one of the lines goes like this:
"HIWORD() and LOWORD() are macros defined by windows that single out the two high bytes (High Word) of a 32 bit value (0xFFFF0000) and the low word (0x0000FFFF) respectively."
It''s not that I don''t understand the passage or anything, I just don''t like to go on if there''s a concept like that that might come back and bite me in the ass later on. And btw, those look very much like functions... are they?
"HIWORD() and LOWORD() are macros defined by windows that single out the two high bytes (High Word) of a 32 bit value (0xFFFF0000) and the low word (0x0000FFFF) respectively."
It''s not that I don''t understand the passage or anything, I just don''t like to go on if there''s a concept like that that might come back and bite me in the ass later on. And btw, those look very much like functions... are they?
April 12, 2002 04:51 AM
A macro is like a string substitute that pretends to be a function. (warning: macros are not type safe!!)
// Macro for converting Radians into Degrees
#define RAD_DEGREE(R) ((R/6.28)*360.0)
Precompiler will substitute RAD_DEGREE(x) in the source code into "((x/6.28)*360.0)".
A macro is usely made to reduce the amount of typing and remembering of small complex statements that are used alot but aren''t large enought to consider for a function.
The macro HIWORD simply shifts the upper 16 bits in a 32 bit value down to the lower 16 bits.
The marco LOWORD simply masks off the uppermost 16 bits of a 32 bit value to leave only the lower 16 bits.
These macros make it easier to obtain the Upper or Lower word in a double word value because you don''t have to remember the operators involved to do so.(Hence fewer bugs) And getting these words are a very common programming task.(Old days: Far Pointers)
I hope this helps.
// Macro for converting Radians into Degrees
#define RAD_DEGREE(R) ((R/6.28)*360.0)
Precompiler will substitute RAD_DEGREE(x) in the source code into "((x/6.28)*360.0)".
A macro is usely made to reduce the amount of typing and remembering of small complex statements that are used alot but aren''t large enought to consider for a function.
The macro HIWORD simply shifts the upper 16 bits in a 32 bit value down to the lower 16 bits.
The marco LOWORD simply masks off the uppermost 16 bits of a 32 bit value to leave only the lower 16 bits.
These macros make it easier to obtain the Upper or Lower word in a double word value because you don''t have to remember the operators involved to do so.(Hence fewer bugs) And getting these words are a very common programming task.(Old days: Far Pointers)
I hope this helps.
Thanks to both of you for the input. I think I get it mostly. From what anonymous said, it sounds like you are describing an inline function. There must be a lot of similarities and differences between macros and functions, but I''m sure they''ll sink in as I program more...
April 12, 2002 05:02 AM
Yes a macro kinda is like an inline function. However, in c++ an inline function''s parameters will be type safe.
Type safe? Does that mean that a function will convert the variable types in a statement (eg: convert int to float) and a macro will not, or do you mean something else?
April 12, 2002 05:15 AM
Let''s say the calculation a macro is doing is dependent on a specific type of variable. But the programmer codes a different type by accident. The precompiler will not check this situation out before generating the code.
However, when a function is compiled the parameters types passed to it must match or you will get a compiler error.
(preventing a possible run time bug that is difficult to track)
So, using inline functions instead of macros is safer.
However, when a function is compiled the parameters types passed to it must match or you will get a compiler error.
(preventing a possible run time bug that is difficult to track)
So, using inline functions instead of macros is safer.
I understand your desire to want to understand them and yes, if you plan on learning C/C++ you''ll want to know what they are and how they work.
They might look like functions because of the parenthesis and the parameters but they are not. No doubt you''ve also seen #defines in some code before - usually to provide a name to a commonly used number. These are quite common in windows (and in general) - all of the window procedure messages are defined this way - WM_CREATE, WM_SIZE, WM_PAINT, etc.
What happens to these defines is that before your source code is actually compiled into an obj file, it is run through a preprocessor which replaces these names with the numbers they represent and after all the replacements are performed, that code is sent along to the compiler. The preprocessor also inserts the contents of any files that have been marked for inclusion (eg. #include <windows.h>. The preprocessor itself is another topic, albeit closely related.
Ok so lets take it to the specifics of the HIWORD and LOWORD macros. Here is how they are defined.
What these two macros do is to extract the high 16 bits and the low 16 bits from a 32 bit number - that is the hiword and the loword from a dword. How they do that is another topic. I assume you are familiar with WORDs and DWORDs.
For the sake of explanation let''s define a dword
DWORD mydword = 0x12345678;
And then lets break it parts using those macros
WORD hiword = HIWORD(mydword);
WORD loword = LOWORD(mydword);
The preprocessor will expand that macro back into the form it was defined as - inline - that is - it will substitute the macro definition at the point where the macro is used. So when the code is finally sent to the compiler it actually looks like this:
WORD hiword =((WORD) (((DWORD) (mydword) >> 16) & 0xFFFF));
WORD loword =(((WORD) (mydword)) & 0xFFFF);
Notice how the macro expanded. HIWORD was replaced by the statement that followed it with the "mydword" parameter in place of the "l". The extra casting is to compensate for the lack of type checking available from a macro, so that the value returned will correspond with a WORD type.
For more details on macros and the C preprocessor, you might want to take a look at the comp.lang.c faq. It will have more information on them than the comp.lang.c++ faq will because macros are more of a C thing than a C++ thing. In fact, many C++ afficianados hate them because they lack type checking and can introduce hard to find bugs. That doesn''t mean you should hate them too, like any tool, they serve their purpose.
They might look like functions because of the parenthesis and the parameters but they are not. No doubt you''ve also seen #defines in some code before - usually to provide a name to a commonly used number. These are quite common in windows (and in general) - all of the window procedure messages are defined this way - WM_CREATE, WM_SIZE, WM_PAINT, etc.
What happens to these defines is that before your source code is actually compiled into an obj file, it is run through a preprocessor which replaces these names with the numbers they represent and after all the replacements are performed, that code is sent along to the compiler. The preprocessor also inserts the contents of any files that have been marked for inclusion (eg. #include <windows.h>. The preprocessor itself is another topic, albeit closely related.
Ok so lets take it to the specifics of the HIWORD and LOWORD macros. Here is how they are defined.
#define HIWORD(l) ((WORD) (((DWORD) (l) >> 16) & 0xFFFF))#define LOWORD(l) (((WORD) (l)) & 0xFFFF)
What these two macros do is to extract the high 16 bits and the low 16 bits from a 32 bit number - that is the hiword and the loword from a dword. How they do that is another topic. I assume you are familiar with WORDs and DWORDs.
For the sake of explanation let''s define a dword
DWORD mydword = 0x12345678;
And then lets break it parts using those macros
WORD hiword = HIWORD(mydword);
WORD loword = LOWORD(mydword);
The preprocessor will expand that macro back into the form it was defined as - inline - that is - it will substitute the macro definition at the point where the macro is used. So when the code is finally sent to the compiler it actually looks like this:
WORD hiword =((WORD) (((DWORD) (mydword) >> 16) & 0xFFFF));
WORD loword =(((WORD) (mydword)) & 0xFFFF);
Notice how the macro expanded. HIWORD was replaced by the statement that followed it with the "mydword" parameter in place of the "l". The extra casting is to compensate for the lack of type checking available from a macro, so that the value returned will correspond with a WORD type.
For more details on macros and the C preprocessor, you might want to take a look at the comp.lang.c faq. It will have more information on them than the comp.lang.c++ faq will because macros are more of a C thing than a C++ thing. In fact, many C++ afficianados hate them because they lack type checking and can introduce hard to find bugs. That doesn''t mean you should hate them too, like any tool, they serve their purpose.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement