p
The value of a pchar.
What do you mean by "value"? The pointer or the character it is pointing
to? It seems that p sometimes means the first and sometimes the latter.
p^
the char pointed to.
Is this the same as p?
I don't think you can say anything from pure syntax without bringing in the
typing. The fact that the pointer type required ^ in the past so that you
could make the distinction in this case is therefore negiable.
I don't understand what you mean here. If I write a constuct (like "p")
it should mean the same in all circumstances. Otherwise it's becoming
tricky when you need to think about the context too when writing code.
To put one on top, the meaning is even context dependent (using it in an
expression or as a paramater of a function may give it have different
meanings).
True, but that is due to additional conversions in the expression, not the
strict meaning of the notation.
Again I don't understand what you mean with "additional conversions". If
I want to access a pointer or its address or the data it is pointing to
I should have an unambiguous, uniform and different syntax for all these
3. But this is no longer the case.
I am not sure why following the strict logic would generate more work.
Because when you are converting, (and then I mean manual or semi-automatic,
because reliable automatic conversion is hard), then the small errors that
this leads to can cost you days of debugging work.
Why that? In Turbo Pascal times I often coded complex nested data
structures with records, arrays and pointers pointing to them. Then it
often happened that I accidentaly used a pointer where I should have
used the dereferenced pointer (or vice versa) but the compiler
immediately raised an error and showed it to me. Now the compiler starts
beeing smarter than I am and guesses what I could have meant. That's not
very debugging friendly.
That bit of code: yes. However not having these is not an option either,
since it makes interfacing costly and hard to maintain, which is why these
features trickled in. And you are incompatible with Delphi and also MUST
convert there.... (not entirely true, some of them were in FPC first, due to
its own particular needs)
Regarding arrays and pointers I can't see your problems. If in C a
pointer is required you can use one in Pascal too. For function
parameters you can use by reference or by value (to mimic what C does
with pointers). So where is the problem?
If it hadn't been for Delphi compatibility, the extensions maybe could be
limited to a certain mode, or unit type. (since modes are nowadays global
per unit, if there was no delphi compatibility, the dialect selection could
be in the unit declaration)
Yes, Borland was the culprit who introduced all this to Pascal. I was
realy disappointed about it at that time. But Free Pascal is no longer a
slave of Borland so could correct their errors.
I don't think a handful of extensions are that bad. If it bothers you so
much, submit patches for directives to turn them on/off.
If I would change my code only I would have an island solution. Reading
code from others (for example Lazarus source code) would still be a
problem. It is already a problem that no Pascal standard exits anymore.
Adding yet another variant is not good. I once thought that Pascal was
superior to other languages because of it's clear and strict concept but
now there is no longer *the* Pascal language anymore.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
