First i will note that what i state is not an error or bug in free
pascal, but it is somehow unclean implemented.
The decision for modifiers like cvar or cdecl to be an
token or an token relies on context information. But what is
that context? An example:
type
name=procedure;
cdecl=integer;
In our previous episode, Joerg Schuelke said:
[ Charset UTF-8 unsupported, converting... ]
> First i will note that what i state is not an error or bug in free
> pascal, but it is somehow unclean implemented.
> The decision for modifiers like cvar or cdecl to be an
> token or an token relies on c
Am Thu, 28 Apr 2011 18:22:38 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> In our previous episode, Marco van de Voort said:
>
> No, since modifiers can be in any order, it could be a lot more than
> two tokens.
>
I think if the compiler reeds the token he needs a lookup of
only
Joerg Schuelke schrieb:
First i will note that what i state is not an error or bug in free
pascal, but it is somehow unclean implemented.
The bug resides in the dirty Delphi OPL definition.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.
Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrich :
> The bug resides in the dirty Delphi OPL definition.
>
Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.
If you consume a token as or in
respect of the right context of one token,
In our previous episode, Joerg Schuelke said:
> > No, since modifiers can be in any order, it could be a lot more than
> > two tokens.
> >
> I think if the compiler reeds the token he needs a lookup of
> only one token to decide: is used as a or a
> token.
No, since if the next token is "depre
On 29/04/2011 09:25, Marco van de Voort wrote:
In our previous episode, Joerg Schuelke said:
No, since modifiers can be in any order, it could be a lot more than
two tokens.
I think if the compiler reeds the token he needs a lookup of
only one token to decide: is used as a or a
token.
No,
In our previous episode, Martin said:
> >> only one token to decide: is used as a or a
> >> token.
> > No, since if the next token is "deprecated" he has the same devilish
> > tradeoff.
>
> Not that I am advertising to change it, but the next token wouldn't be
> deprecated ever (that would be
Am 29.04.2011 00:02, schrieb Joerg Schuelke:
Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrich:
The bug resides in the dirty Delphi OPL definition.
Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.
If you consume a token as or i
