Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:
Am 26.12.2017 13:33 schrieb "Giuliano Colla"
<giuliano.co...@fastwebnet.it <mailto:giuliano.co...@fastwebnet.it>>:
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
feature :
- All architectures should be supported (now it's only for x86_64
- symcpu.pas).
It might be possible to implement this in a platform independent way
that might simply need to expand the capabilites of "absolute".
The feature in itself is platform independent.
The only catch is that in pdecvar.pas (where variable declaration is
handled) there's a per platform hook for each symbol type, in order to
allow for special handling of some features.
For consistency I did follow the same rule, which is used for all the
other declarations, disregarding whether they're platform independent or
not.
As a consequence, for each supported platform you must add in its
specific symcpu.pas a type entry:
tcpubasedvarsym = class(tbasedvarsym)
end;
tcpubasedvarsymclass = class of tcpubasedvarsym;
and a line of code:
cbasedvarsym:=tcpubasedvarsym;
As this is tedious, I've only done it for the platform I'm using
(x86_64/symcpu.pas). To deploy the feature, the same lines must be added
in each platform symcpu.pas unit. There's no more that that.
- It should be decided if to make the feature generally available,
or conditioned by an {$IFDEF FPCHASBASED}
- It should be decided if the feature should be available in all
modes or only in a selected number of modes (what of TurboPascal
Mode or Delphi Mode?).
Rule of thumb: new features added as a separate mode switch, no
FPC_HAS_* define necessary as by definition this can be done with
version checks (there is only one trunk version, namely the current one).
- It should be decided if error messages should be specific for
the BASED construct or common to the ABSOLUTE one, slightly
rephrasing the error message.
Might be one or the other depending on the message.
- It should be decided if internal error # which currently keep
the same number of the nearby ABSOLUTE internal error should be
given new values.
Internal errors shall always be unique as they are used to find the
error location, even for copy pasted code.
What's the rule to avoiding clashes? I gathered sort of YYYYMMDD## is it
correct?
Giuliano
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
