[fpc-devel] Macro Processing

Daniël Mantione daniel.mantione at freepascal.org
Sun May 15 13:26:03 CEST 2011

Op Sun, 15 May 2011, schreef Joerg Schuelke:

> 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.

Even if you have a project where RTTI is not needed, you would be thumb 
not to use it instead of a macro. Really. There is no drawback.

> 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.

You are completely mistaken. This is what C++ uses RTTI for. FPC (nor 
Delphi) does not use RTTI for this purpose at all! We have the typeof 
function for this, which returns a pointer to the VMT. I even have no idea 
wether the RTTI can be used for this purpose at all :)

> 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
> information.

You are wrong again. Ansistrings/widestrings/variants and so on make use 
of RTTI.

> To get the associated name of an enum? Thats compile time information.

Then show a practical example where having it at compile time is a real 
benefit. Please understand it clear: We are not against new features, but 
there must be a benefit.

> 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)

Feel free to come up with examples and convince us. They need to be 
examples of code that is much more awkward to write without macro's.


More information about the fpc-devel mailing list