[fpc-devel] Macro Processing

Joerg Schuelke joerg.schuelke at gmx.de
Sat May 14 19:02:03 CEST 2011


Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl <florian at freepascal.org>:

> Am 14.05.2011 17:30, schrieb Joerg Schuelke:
> > Am Sat, 14 May 2011 17:04:45 +0200
> > schrieb Joerg Schuelke <joerg.schuelke at gmx.de>:
> > 
> >>
> >> I repeat, I have really nothing against RTTI, but I state that it
> >> comes from a high level language extension.
> >>
> > By the way this RTTI thing comes from the argument: Do not use a
> > macro, instead do it this way. But this forces me to use RTTI,
> > which is possibly not what I want.
> 
> Then you should use C ;) RTTI is something which makes life easier and
> prevents mistakes.

I do not understand this C argument, I swear I am an pascal man! ;(
Again, nothing against RTTI, but I do not like to be forced to use it.

> 
> > 
> > Most of the arguments against macros where of this kind.
> > 
> > You can do it an other way, using ...
> > 
> > But this way I can show you even OOP is useless :) what I do not
> > believe.
> 
> True. But the point is: macros are something rendering code easily
> unreadable if used wrong ...

Yea, thats why the explicit expansion of the macros, even the dumbest
can see it is a macro expansion {$expand macro(1,2,3)} the words you
suggests.

By the way the RTTI approach do not solve the problem, if there is one,
we did not see that:

	enum(en1,en2,en3,...);

          ...

	strarr:array[...] of shortstring={
          str(en1),
          str(en2),
           ...
        }

does only half of the work. You have to keep them in sync furthermore,
see the order.

Sometimes we shoot a little to quick, so do I, sorry for that.

Regards
	Jörg





More information about the fpc-devel mailing list