Am 2016-12-24 um 15:20 schrieb Bernd Oppolzer:
Am 24.12.2016 um 14:21 schrieb Mark Morgan Lloyd:
On 24/12/16 12:30, Bernd Oppolzer wrote:
Regarding ^:
"my" compiler supports different representations for the pointer
symbol,
and for other
critical symbols, too:
^ @ -> for the pointer symbol (I use -> most of the time)
[ (. (/ for arrays
{ (* /* for comments ("comment" is supported, too, for historic
reasons)
/* was the form used in the first edition of Wirth's description of
Pascal (might have been before Jensen was there to help out).
I converted all relevant sources (including the compiler itself) to ->,
so this would be ok for me.
This is indeed a very well known C style.
PTRADD, PTRDIFF and so on ...
This is not C style but with a minor macro helper something like this is
quickly added to a typical C program.
The difference between two pointers is defined as the number of elements
of the pointer type.
The addition or sum of two pointers is missing a bit of a straight
forward logic for me.
Advanced coding style recommendations (e.g. MISRA standards) would tell
you not to use such pointer math
because such constructs have a higher chance to sometimes mislead the
performing programmer and thus would more likely lead up to codes with
functional bugs.
The first answer for such operators often is: use the right container
for the value you are in need and avoid all those operators.
And the second answer is: If you are really in the true rare need (e.g.
for system programming, ring buffers, atomic operations, code sizes +
register savings + extreme efficiency) then keep these codes and data
very isolted, very well documented and finally deeply tested for all
operating conditions.
Maybe pandora's box, but I need this to do some of the more systems
related
work. For example: I rewrote the LE storage management in Pascal and
made it
available to the Stanford Pascal runtime (new functions ALLOC and FREE);
this works perfectly with Hercules and VM; it still has to be tested
with Windows - Linux - OS/2.
Is the your lower end of those module touching on a system API level for
that?
(e.g. the Linux ABI, OS/2 system peronality, WIN32 api - rather than
malloc()/free() as a C standard library provides it)
I added /* to the list of allowable symbols for comments, because it's
what I knew
from PL/1 and C. Comments have to be terminated by the same symbol which
started them, and: they may be nested (as with FPC).
From a C program portability view I would futher "tick" for the support
of the "//" comment operator as a single sided one.
On the other side, even for ages there is the option of pascal-2-c
converters (p2c) that do the other way around, but would have some
smaller problem if such a token was suddenly added. If sources of the
tool are available then someone that is in need for support could solve
it easily.
just my 2 euro cents.
regards and good christmas times.
-Alex.
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
