I found an actual use for MACROS

[jamie]

Been working on a large C++ translation and there are so many circular loop errors in the interface section due to required units I had to set many of the function return definitions in the interface section to TOBJECT, which caused havoc in the implementation section with all the Type Casting that was required, because there I can include the required units to get the TYPES.

I found a use for MACROS 
Uses ,,,,, etc

{$MACRO On}
{$DEFINE AShortFunctionName:=TheTrueFunctionClassResults(A_Function_THAT_RETURNS_ONLY_TOBJECT)}


With all of this, I no longer need to type cast all these items in the implementation section.

in the end, it's still the same in source for the compiler but makes your code look a lot nicer and less complex looking.

The only issue I see so far with this is CODE tools does not seem to know how handle this?

Jamie

[Thaddy]

Another disadvantage is that macro's are unit local.
Hence I put them in include files.

[marcov]

And how is it better than an inline function that does the same?

[Zvoni]

Boy, do i hate macros in C (Never had to translate C++, but the same applies)

If i encountered a macro in C, i usually wrote it as a nested Procedure/Function.
if later on the same macro got called by another function, i moved the nested Proc outside

marcov's argument as inline not withstanding (which is what the c-compiler actually does: inlining the macro at the position of the call)
another approach might be anonymous function at the position of the call

EDIT: *sigh*
I'm an Idiot
My answer above has nothing to do with Jamie's post.....

[jamie]

And how is it better than an inline function that does the same?

Only one line to define

I do use inline if parameters are required.

Jamie

[Thaddy]

Yes, you are right: use of macro's as you propose and I do is a fingers and keyboard saver.

For others: those are not parameterized macro's. These are not possible in FPC's macro system and you may easily mis-read what Jamie means. He writes the full parameter specialized for every case..

[jamie]

I just tried an InLine or non-Inline. can't do it.

I would need to make the prototype in the interface with the resulting type I need but then I need to include the required unit and that in turn ends with a circular reference error.

The Inline method does not have access to the current class instance (SELF) so it cannot see the inner TOBJECT method I am trying to cast simply.

The MACRO stays as it is the only thing that works because it is defined in the IMPLEMENTATION section at the start just after the USES list where I do include the required unit.

Jamie

[marcov]

In my work job, I use C for embedded work, and there I use macros a lot.

Some reasons are legacy (migrated to a compiler that could do C99/static inline pretty late), some not.  In the past we used 20-33MIPS/16-bit and even less (8-bit, 8MIPS) CPUs, while new prints now are for 32-bit 200MHZ/MIPS parts.

Most macros are basically pin aliases in the board definition, so that firmwares can migrate to later boards which might shuffle pins.

Some others are as aliases for peripherals (which are basically register names), which you could see as a kind of generic. The peripheral register names are created with some ## magic.

If I would start new, I probably would go to a more arduino level with a bit more runtime overhead. But most firmwares are relative small in absolute size (20-30kb) and lines (5000 lines main C file is already much, with maybe some more in libraries)

I do sometimes wonder how I would handle this in Pascal (go with the more arduino like option, or use an extra macro processor?).

I also have about 100kline C++ code. That is not embedded, so I don't really use macros there.