On Wed, 6 Mar 2013, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Unfortunately pascal macro's are rather limited compared to C. I know I know,
you could potentially open up a can of worms, but sometimes more control is
required.
There is nothing restraining anybody using an external macro processor. It
is just that we don't want to support it :-)
Actually, I'd suggest that there is: the difficulty of integrating an
external macro processor with the standard build process (i.e. it's not
just another stage in a makefile).
It is. Export all known sources to a new dir for the compiler through the
preprocessor.
I've had to deal with colleagues in the past who thought it was entirely
acceptable to make manual edits to compiler output (typically on Intel
blue boxes) before running it through the assembler, and it's very high
on my list of Thou Shalt Nots.
General preprocessor usage is on mine. I use preprocessors and
codegenerators all the time, and have no problem whatsoever with it.
What I have a problem is, is to give that formal statement, so that future
development on the compiler will be limited by it in all its gory glory.
IMHO we should simply have a directive that is either cdecl or stdcall
depending on the platform
+1
I proposed libcall about 10 years ago - if not longer. OSCall or NativeCall.
Whatever. Just not a macro.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
