[fpc-devel] MACRO - correct syntax?

[Florian Klämpfl]

Am 25.02.2018 um 18:21 schrieb Giuliano Colla:
> Il 25/02/2018 13:55, Florian Klämpfl ha scritto:
> 
>>> To limit their use. 
> 
> Well, just for sake of argument, it appears to me a rather drastic approach.
> 
> You may write other similar pages on stackoverflow, telling why Dereferencing is evil, Typecasting
> is evil, or why "Absolute" or the "with" construct are evil.  All of them, if misused, can lead to
> unexpected results, with code hard to read, easy to misinterpret, and hard to debug. Nonetheless
> they're part of the language, and, properly used, are useful programmer's tools.

http://www.gnu-pascal.de/gpc/Preprocessor.html, nobody prevents people to run a preprocessor before
FPC gets the code.

> 
> Most of the drawbacks of macro arguments can be easily overcome if
> a) The listing of preprocessor output is generated.

... which would be a huge effort in FPC as at the point macro are replaced, everything is already
tokenized, comments etc. are already stripped.

> b) The preprocessor output is provided to the debugger as the actual program source
> None of the two should require a titanic effort!

So why is it still a problem for C programmers?

> 
> IMHO macro arguments, if properly used, may be a valid additional programmer tool.

This can be said for a lot of things we do not implement in FPC.

> 
> E.g. Converting a C program to Pascal I had:
> C code:
> 
> #define EXCH_INITIALIZER(nam) \
>     {NULL,NULL,NULL,NULL,NULL,PTHREAD_MUTEX_INITIALIZER,nam}
> ....
> EXCHANGE_DESCRIPTOR cp_ready_ex = EXCH_INITIALIZER("CP_RDY");
> 
> 
> Lacking macro arguments, the equivalent declaration in fpc became:
> 
> cp_ready_ex: exchange_descriptor = (
>  message_head : Nil;
>  message_tail : Nil;
>  task_head : Nil;
>  task_tail : Nil;
>  exchange_link : Nil;
>  mutex : (__m_reserved: 0; __m_count: 0; __m_owner: Nil;__m_kind: 0;__m_lock: (__status: 0;__spinlock:0));
>  name: ' CP_RDY';);
> 
> (and I had quite a number of them!)
> A lot of error prone typing, just to provide the only useful information, i.e. the readable name of
> the thing.

For every language feature some rare use case can be found.