{$MACRO ON}
{$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}
Begin
   _CTASSERT(1,1,'Constant failed.');
end.

Am 25.02.2018 03:01 schrieb "Ozz Nixon" :

{$MACRO ON}
{$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}
Begin
   _CTASSERT(1,1,'Constant failed.');
end.

Macros with arguments are not supported.

Regards,
Sven

Ozz Nixon wrote

{$MACRO ON} {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);} Begin _CTASSERT(1,1,'Constant failed.');end.

I don't believe parameters are supported :-(

Why so sad? They are not supported on purpose :)

Florian Klämpfl wrote

Am 25.02.2018 um 11:12 schrieb Mark Morgan Lloyd:> On 25/02/18 02:15, Ozz Nixon wrote:>> {$MACRO ON}>> {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}>> Begin   _CTASSERT(1,1,'Constant failed.');end.> > I don't believe parameters are supported :-(> Why so sad? They are not supported on purpose :)

Because it messes up what the OP was trying to do, which is not necessarily something to feel good about.

And as far as "doing it on purpose" is concerned, you might or might not be acquainted with what happened when the illustrious Brigadier Gerard tried his hand at cricket...

https://www.arthur-conan-doyle.com/index.php/The_Brigadier_in_England

:-)

Am 25.02.2018 12:14 schrieb "Mark Morgan Lloyd" <

:

Because it messes up what the OP was trying to do, which is not necessarily something to feel good about.

Yes, we definitely feel good about this, because we don't *want* parameter support in FPC's macro handling.

What the author wants to achieve here can also be done using a procedure marked as inline. As long as the unit containing the procedure is rebuild when assertions are enabled or disabled everything will work as expected and even the whole call will disappear if it isn't needed. Much cleaner than a preprocessor.

Regards,
Sven

Il 25/02/2018 13:15, Sven Barth via fpc-devel ha scritto:

Yes, we definitely feel good about this, because we don't *want* parameter support in FPC's macro handling.

Maybe I'm obtuse, but I fail to grasp the reason why. Can you elaborate a bit more?
Thanks

Giuliano

To limit their use. More can be read here:
https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives

The same would would apply to pascal as well.

Well, probably usage is the better word, meaning being less used.

Thank you Sven! I saw all of the threads on this topic in 2011, but, figured I would ask here if it had changed, and I was just doing it wrong. We are in the process of porting Minix 3 source to Free Pascal (Andrew T. tells me it can’t be done, and I know FPC can handle it). I just wanted to keep the C macros close so he can see I did an automated conversion not a logic conversion.

Thanks to everyone else on this topic, but “not supported” is fine with me.

Ozz

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.

Most of the drawbacks of macro arguments can be easily overcome if a) The listing of preprocessor output is generated. b) The preprocessor output is provided to the debugger as the actual program source
None of the two should require a titanic effort!

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

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.

Giuliano

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.

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

Il 25/02/2018 18:34, Florian Klämpfl ha scritto:

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

That's a constructive suggestion.

If fpc doesn't implement an actual preprocessor, but macro expansion is part of the source parsing, then I must agree with you that the effort required wouldn't be justified by the benefits obtained.

Thank you for your time.

Giuliano

Giuliano Colla wrote

Il 25/02/2018 18:34, Florian Klämpfl ha scritto: > http://www.gnu-pascal.de/gpc/Preprocessor.html, nobody prevents people > to run a preprocessor before> FPC gets the code. That's a constructive suggestion.

Easily put in the makefile [DUCKS] :-)

Giuliano Colla wrote

Well, just for sake of argument, it appears to me a rather drastic approach.

While you can do really cute stuff with Macros in C, using the (or doing a) debugger for code that uses macros is a horrible PITA.

Nonetheless it would be nice if there would be a predefined way to squeeze the sourcecode through the gcc macro processor, if anybody really feels the need to do so.

-Michael