On 16/05/2011 01:30, Joerg Schuelke wrote:
const
infoarr:array[callenum] of inforec={
{id:proc1;name:'proc1';address:@cb_proc1},
{id:proc2;name:'proc2';address:@cb_proc2},
{id:proc3;name:'proc3';address:@cb_proc3},
{id:proc4;name:'proc4';address:@cb_proc4},
{id:proc5;name:'proc5';address:@cb_proc5},
{id:proc6;name:'proc6';address:@cb_proc6}
}
What I possibly would do is:
{$Makro entry(n):={id:proc %% %n%; // concat with parameter
name:'proc' %% % %n%; // concat with str par
address:@cb_proc %% %n% // concat with parameter
}
}
And that is exactly where macro turn into red hot iron.
The same could be used to say define a procedure, and the name of the
procedure would be the result of some concatenation.
Or define a macro the name of which is the result of some operation....
I have seen that in C, macros generating macros.
As the result, even if you knew you where looking at a macro, you had no
way to find where it was declared. Because the declaration did not
contain it's name (but concatenated it from many pieces).
Search for the full name => the declaration is not found.
With the above, you could at least define procedures, that can not be
found by search.
And over time it will happen. With macro support like this, people start
building there macro-libraries. And eventually end up with things they
never even intended themself.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
