Lars ha scritto:
It's actually a common mistake. Also @s vs "s", and @s[1], it can be
confusing.
It's one thing I don't like about unsafe languages, pointers, and such
stuff. It's as if we are programming in advanced C, or C++. Common,
pointer mistakes? this is C? Really? Can't we make it safer? LOL.
What could be done to make this safer? I don't know. What does java do in
a situation like this? Could we learn from it?
The only "clean" solution I'm aware of is is the one used in old times
by PLM, which completely banned the "implicit pointer" born with C language.
If you just have a local string (or data structure), the name must be
"qualified". If /s/ is a string you must either use /@s/ to indicate the
pointer to the string or /s[n]/ to indicate an element of the string. If
/b/ is a structure, /b.something/ is valid and/@b/ is valid, but the
usage of /s/ or /b/ alone is not allowed.
Whenever you're not dealing with local, static data, then you have the
"based" construct, which allows to reserve storage for a pointer, and
describes what the pointer points to, providing both strong type
checking, and an easy way to dereference when required. Again any
ambiguity is impossible.
An example of the PLM syntax is:
Declare p pointer;
Declare s based p (256) Byte;
and also, if required,
Declare w based p(128) Word;
I've implemented an extension of FPC to support the "based" construct,
which I find very useful, to get rid of the c-style p^something, and to
make the code more readable and easier to maintain.
However I've never submitted my personal patch, because when I proposed
it, it didn't rise any interest, and I'm always two steps behind with
FPC versions....
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
