On Fri, 22 Jun 2018, Ryan Joseph wrote:
On Jun 22, 2018, at 3:19 AM, Marc Santhoff <m.santh...@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.
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
