Hi,
as you might know, GPC predefines some symbols depending on the dialect options given on the command-line, e.g., `__BORLAND_PASCAL__' if `--borland-pascal' was given, so programs/units can check the dialect in `{$ifdef}' directives.
Actually, I'm not sure if it's used at all -- generally it's better to write a program/unit for one specific dialect and, especially in case of units, put the respective dialect option (`{$gnu-pascal}' if the default is wanted) at the top, so it doesn't matter if the main program is compiled with a different dialect.
However, the main problems with those symbols are that the internal handling is a little ugly and, what's more, that the symbols don't change when the dialect is changed via a compiler directive. E.g., the following program writes 3 times 'BP' if compiled with `--borland-pascal' and 3 times 'GPC' if not (unlike what one might expect):
program Foo;
begin {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif}
{$gnu-pascal}
{$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif}
{$borland-pascal}
{$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} end.
Of course, it would be possible to change the behaviour, but this will take some effort and it would be rather obscure having the dialect options change the defines (e.g., what if the symbol corresponding to the previous dialect was defined manually, should it still be unset?).
However, there's already an alternative that works well, that's `{$ifopt}'. The following program outputs what one would expect.
program Foo;
begin {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif}
{$gnu-pascal}
{$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif}
{$borland-pascal}
{$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} end.
`{$ifopt}' has been supported for quite some time, at least before GPC 2.1, so programs will not require a new GPC version or a GPC version conditional when changed to `{$ifopt}'.
Therefore, to avoid confusion about the behaviour of the symbols (and to clean up GPC as always), I'd like to drop them. Any objections?
Frank
On 15 Nov 2002 at 17:15, Frank Heckenbach wrote:
[...]
`{$ifopt}' has been supported for quite some time, at least before GPC 2.1, so programs will not require a new GPC version or a GPC version conditional when changed to `{$ifopt}'.
Therefore, to avoid confusion about the behaviour of the symbols (and to clean up GPC as always), I'd like to drop them. Any objections?
None from here ...