[fpc-devel] Macro Processing
daniel.mantione at freepascal.org
Sat May 14 20:46:30 CEST 2011
Op Sat, 14 May 2011, schreef Joerg Schuelke:
> I think of this a little different. Maybe more from an other
> perspective. For me RTTI is a level of language extension. Like OOP, or
> generics, or inheritance. Macros are very low level (if you have them).
RTTI *allows* for language extensions, like str/val for enums. RTTI by
itself are just data structures describing Pascal types, emitted
automatically by the compiler. Language extensions can use those data
structures to provide their functionality.
> It is not that I think that I would use a macro instead under all
> circumstances. But it should be possible to do it without RTTI which is
> of higher level in the language.
I still don't see why it should be possible to do it without RTTI. But the
question is, is the unknown reason that you don't want to use str a
justification for adding the can of worms that is called macro's?
> The principle is do not use it if you do not like it. That should not
> influence the rest of the language. This way I think that it is not
> that bad to have a small, but powerful macro expander incorporated.
It's not that bad, but it should make something possible. Until now I
haven't seen many bright examples of things that cannot be elegantly
> 52 bytes of data. And the RTTI code?
Not much. Converting an enum to a string is a single procedure. It's
quickly won back if you use the feature a few times. Actually this is a
nice story about the hidden costs of language features. The procedure
would be extremely simple (lookup a pointer to the string in an array,
return the string), but FPC supports non sequential enums:
The majority of the code in the procedure that converts an enum to a
string deals with handling this special situation (don't worry: normal
enums are still a simple lookup). Often when you add features, it has
unforseen consequences and it can be a complicated effort to make
everything together well enough. This is why you want to be carefull
adding new features.
> What if you do not smartlink?
Then you get so much extra code in your exe that the RTTI is still a small
and irrelevant portion. Actually in the past you could disable RTTI
generation, but it was too sensitive for bugs. Removing unused code & data
is the task of the linker, we decided to make the linker do what it is
> 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.
Hmmmm... For the same reasoning you could say inline functions are ugly
and you want not to be forced to use inlining.
The point is that every time you can avoid a macro you win on code
clarity, compiler speed (no time spent on evaluation & expansion),
debugability, parsability by IDE's, and so on.
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
We don't want to force you to use RTTI, but our point is that there is
proper solution to achieve the same benefit that the macro approach gives.
> But this way I can show you even OOP is useless :) what I do not
While I do believe in the merit of OOP, there are many dubious OOP
features that you can criticize in a valid way, escpially because few of
those features open new possibilities. But unfortunately it's a waste of
time; we need this for compatibility.
More information about the fpc-devel