[fpc-pascal] Proper preprocessor?

Michael Van Canneyt michael at freepascal.org
Fri Jun 22 07:21:21 CEST 2018



On Fri, 22 Jun 2018, Ryan Joseph wrote:

>
>
>> On Jun 22, 2018, at 3:19 AM, Marc Santhoff <M.Santhoff at web.de> wrote:
>
>> <Pascal>
>> function HOFFSETP(rectypevar: pointer; fieldvar: pointer): longint; inline;
>> begin
>> 	HOFFSETP := longint(fieldvar - rectypevar);
>> end;
>> 
>> H5Tinsert(s2_tid, 'c_name', HOFFSETP(@s2[0], @s2[0].c), H5T_NATIVE_DOUBLE);
>> H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
>> </Pascal>
>
> So there was a solution but I can see why the C macro version was easier to look at it. Was that not a good reason to use a macro? I like how the macro cleaned that up. Sven’s suggested answer of "@s1_t(nil^).a” is even more obscure imo.

The above qualifies IMHO as definite proof that macros are for real corner cases. 
It must have been somewhere in 1988 when I last needed such code.

>
> If you guys don’t mind I may try to remember and collect the uses of
> macros I’ve wanted at random times through out the year and see if there
> is indeed not practical or good use for them in modern Pascal.
>
> Here’s a macro I like from C. It captures the assert expression and prints it back out into the console (it would halt the program also). Can this be done in Pascal? In C they return the file name and line number also which is really nice.

'Nice' is not an argument.

If someone else assumes that assert() works as expected - i.e. 
throws an exception, then your macro will mess up his code, leading to
unpredictable results.

>From my - admittedly subjective - point of view, your examples only serve to demonstrate 
why we should definitely not support macros...

Michael.


More information about the fpc-pascal mailing list