Re: [fpc-devel] An extension of fpc language: the BASED construct

Il 27/12/2017 15:05, Sven Barth via fpc-devel ha scritto: No matter the syntax that might be chosen for this it will likely be sufficient to handle that feature by an absolutevarsym with a boolean flag or something like that. The difference to an ordinary absolute variable appears to be too

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 27.12.2017 00:54 schrieb "Giuliano Colla" : Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla" : If the idea is not rejected, then a number of refinements (which I'm ready to

Re: [fpc-devel] An extension of fpc language: the BASED construct

Hello folks, As described on my site programming.sirrida.de/pascal_proposals.html#offset I would propose a slightly more general approach to the theme. In contrast to the presented solution my offsets are separated from the base pointer. Calculations with offsets, e.g.: TYPE tr_rec =

Re: [fpc-devel] An extension of fpc language: the BASED construct

On 26/12/17 23:15, Giuliano Colla wrote: Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto:> What does gdb (and possibly other debuggers) make of this? What currently gdb tells (and any other debugger would tell) is : No symbol "Item" in current context. Once the appropriate entries are

Re: [fpc-devel] An extension of fpc language: the BASED construct

Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla" >: If the idea is not rejected, then a number of refinements (which I'm ready to implement) are required to make

Re: [fpc-devel] An extension of fpc language: the BASED construct

Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto: What does gdb (and possibly other debuggers) make of this? What currently gdb tells (and any other debugger would tell) is : No symbol "Item" in current context. Once the appropriate entries are implemented in the debugger symbol table, it

Re: [fpc-devel] An extension of fpc language: the BASED construct

In that case, if the functionality is going to be included, the best course of action might be to restore pre 2.4.0 behaviour, add the ability to use explicit dereference, and bind it to a separate mode switch. Binding it to a mode switch solves the Delphi compatibility reason for removing it.

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 26.12.2017 13:33 schrieb "Giuliano Colla" : If the idea is not rejected, then a number of refinements (which I'm ready to implement) are required to make the feature generally available: My following remarks are independent of an eventual acceptance of the

Re: [fpc-devel] An extension of fpc language: the BASED construct

See: http://tutorial.modernpascal.com/?DataTypes I implemented INTEGER as 32bit, but, if FPC makes it 16bit only, I will go make the change right now. My end-users all know *DO NOT USE INTEGER* it's even in the license agreement. "It is only there for make code compatible w/ Delphi and FPC." I am

Re: [fpc-devel] An extension of fpc language: the BASED construct

I like the concept, I would like to ask that we do not support INTEGER as a type, and be more specific by limiting to SHORTINT, SMALLINT, LONGINT, INT64. That way code snippets are not confusing when you implement 16bit INT logic on a 32bit INT environment. Because I do a lot of documentation for

Re: [fpc-devel] An extension of fpc language: the BASED construct

On 26/12/17 12:45, Giuliano Colla wrote: /In short the BASED construct makes the C-style dereferencing operator unnecessary, by moving dereferencing from code to declaration. In fpc this translates into code looking like this, in this trivial example: var I: BYTE; I1: INTEGER;

[fpc-devel] An extension of fpc language: the BASED construct

Hi fpc developers, here enclosed a patch to the compiler (and ppudump) to support the BASED construct (PL/1 and PL/M style), together with a patch to Lazarus codetools in order to be able to use it with Lazarus IDE. For those unfamiliar with the BASED