[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