[fpc-devel] Macro Processing
nc-gaertnma at netcologne.de
Fri May 13 12:11:06 CEST 2011
Joerg Schuelke <joerg.schuelke at gmx.de> hat am 13. Mai 2011 um 02:07
> The thoughts about further improvement of the macro capabilities of the
> compiler are now so far along that I can post this paper. But it is not
> that short, about three pages.
> Why doing it? There are IDE Macros.
> People do not use all the same IDE, some do not use any. The
> IDE changes much quicker then a language. A strong separation
> between language and IDE is needed.
> Macros are ugly.
> Yes, thats true, but nevertheless they are useful in some
> contexts. Debugging macros from the C world are only one
> example. Repeated code pieces another.
> Macros slow down the compiling process. The expansion is ineffective.
> Thats true only if every identifier has to be checked out for
> possible macro expansion. Hashing the macro identifiers would
> help too.
Compiler errors in macros are often confusing/misleading, because the user does
not see the expanded code. Same for debugger positions and handling.
Macros can confuse other parsers. For example the fcl parser or the ones in
IDEs. Especially imported macros from other units and conditional macros are not
Code editing functions in IDEs are mislead by macros especially conditional
> Thats Delphi inkompatible.
> A separate preprocessor run would solve the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel