....
http://www.codeproject.com/KB/cpp/Macros_vs_Inlines.aspx

Quote:

Function-like macros when used always expand at the point of usage. The function-like macros are pre-processed at compile time, and as a result, there is really no macro existing at runtime. This is why there is an increase in the size of the binary files.

Yet another major setback of the function-like macros is the lack of type checking leading to a high level of type insecurity. The arguments passed on to a macro are never preprocessed. Looks totally harmless, doesn’t it?

Function-like macros and any other type:
The only reason I don't like to use marcos is I thought it will expand your code size at assembler time. But that don't seem to be the case. If a macro is called 10 times to build your windows and furctions and don't add nothing extra, I have no problem with that. but is there more it than that... would 10 expand to 1x,2x 3x,20x, 40x at comply time or is it like un-initialized data which only expand at runtime and use more
memory? If so, I can live with that.

As long as it don't increase the size of the the final file at comply time by much other than the amount expected () I might as well use them.

By saying **expand at the point of usage** This is a difference. Do they mean for each call to a marco do this mean merory continue to grow with each call? Do 100 calls mean 100 extra copies. If so, can we clean up that extra memory and use it for something else.

Anyway, If this is right I can live with that because it's only memory and memory is getting bigger and cheaper these days.

Quote:

Consider the example below which depicts the disadvantage of the lack of type checking. In this example, the result is always the value passed in as the second argument.

I care less of type checking because I'll spend forever on a block of code until I manually check ALL conditions and some... Am Im right to think this way... to not have any need for it.

If a program had 1000 marcos all well written to be safe and fast I see no reason not to use them, finally. If macros only expand in memory that's a bonus to me.

Am I on the right track. The whole world is talking about C++, JAVA etc, I'm talking assembler. It gave me a lot to think about. I want to end my fear of using them. I can get a better understanding from the assembler codes point of view.

fasm macros are compile-time only. There are no function-like macros in fasm, AFAIK. The article you've quoted is about C-specific differences between inline functions and function-like #define macros.

Simply put, macros are convenient feature of compiler to make source more compact and understandable, just as instructions' mnemonics, labels, symbolic constants, expressions and formatter directives are.

Of course, you can go bare-bone and even db the entire output -- fasm allows that (in fact, I often use fasm to rebuild binary files, bitmap fonts for example). Macros allows to make some building blocks for repetitive tasks (structures, API calling conventions, export/import support, resources, etc.)

About code/data size increase: each time you use macroinstruction in your source, it will be replaced with it's contents (that is the part between {} braces) at the preprocessing stage. Tomasz even made stand-alone preprocessor fasmpre from one of the builds (invaluable tool to check for errors in macros), so you can see the source after preprocessing stage but before assembling. Therefore each macroinstruction expands to some source fragment which in turn usually assembles to some bytes in the output file. But, as I wrote above, macros are just a convenient feature, for example, to write instead of However, macroinstruction can do much more than simple substitution (see INCLUDE\MACRO subfolder in your fasm folder for some complex macros).

In short:
1. Macroinstruction is a compile-time feature.
2. Each time you use macroinstruction it will be replaced with some source fragment (albeit probably different each time).
3. Type checking has nothing to do with macroinstruction.
4. Are you on the right track? That depends. Programming with assembler will give you most specific knowledge on how programs works. There is a good joke about programming (how to shoot yourself in the foot in different languages):

The only Macros is use are the struct macros. I actually enjoy inventing the Gun, bullet, foot and trigger along with all the physics to project the bullet.

FrozenKnight,
Macros add some automation for repetitive/tedious tasks. They also combine some simple instructions in macroinstructions, which are, given the proper name and comment, very useful to make sources much more readable. Periodically I review my old programs' sources to inject newly found tricks/concepts, and well chosen macro name as well as comments helps me greatly to understand once again those bithacks I'd developed .
For me, is almost self-explanatory, contrary to 256 dds.

I agree with what you say, Especially with fasmw macro's where you can have a high level feel and organization without the usual high level language bloat. However, It would be good for beginning programmers to refrain from using most macros and program more in the raw. This would allow you to get a good knowledge of the intel instruction set (how different addressing modes works especially), use the mmx/sse1&2&3 instructions, make improvments to the macros themselves, and finally to be able to read crash dump disassemblies.

madmatt

I agree with you too. It's important to know what each used macroinstruction does, but it's much more important to know how macroinstruction does that. For example, I almost immediately replaced in pushd macro (WIN*X*.INC) with just to be sure that I occasionally will not trip over this wire...

Nevertheless some macros are of great utility, like library/import sweet twins. Bare core programming is a great effort in discipline and attention to details, so every bit of help counts, especially for novice.

Good Example. That's something I need to do, I need to pactice my preaching and study the macro library and commands much more in-depth. (by the way, this "fix" should probably be in the next update to fasm. )