[fpc-devel] Macro Processing

Joerg Schuelke joerg.schuelke at gmx.de
Sun May 15 02:39:25 CEST 2011

Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione <daniel.mantione at freepascal.org>:

> Inlining is better that doing the same with macro's, so is the use of 
> str/val better than macro tricks.

Wherever you can!
If I do some low level system work, it is possibly better to do it with
a macro.

If I have a project where rtti is needed anyway, I would be dumb not to
use it instead of a macro, if it fits the needs.

What is the need of rtti: pointer to base classes do not know
to which possibly derived class they point. Thats why *runtime* type
information. All other things which you use in your program do not need
runtime type information, they always know who they are. If I do not
use objects or classes I have therefor no need for runtime type
To get the associated name of an enum? Thats compile time information.

If there is a need for this it should be delivered to me by something
like {$I %enumname%enum%}, I think you would not like to have it this
way. But {$I %color%red%} will hopefully give 'red'. While {$I %color%}
maybe gives then 'red,green,blue' :-)

What is the need of a macro processor:To change the handwritten code in
an automated way. Is this a bad idea? Are there no needs for this?

For example to hold to lists with same entries under all circumstances
in sync. A macro does this in the simplest manner.

If you have an need for changing your handwritten code in an automated
way and you do not have macros, what would you use then? LaTeX? an IDE
tool?, m4? or inventing an compiler feature, but then do not call it
rtti, call it a macro. (thats pretty polemic, don´t worry)


More information about the fpc-devel mailing list