David Emerson schrieb:
I *am* checking sizes before the move, which is why it surprised me that things
were going out of bounds -- the trouble is I forgot the array index [0]
Yes, that happens quite often. Unfortunately, Borland gave up the clear und
predictable context independend Pascal
Jürgen Hestermann schrieb:
David Emerson schrieb:
I *am* checking sizes before the move, which is why it surprised me
that things were going out of bounds -- the trouble is I forgot the
array index [0]
Yes, that happens quite often. Unfortunately, Borland gave up the clear
und predictable
Florian Klaempfl schrieb:
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the
Jürgen Hestermann schrieb:
Florian Klaempfl schrieb:
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storage.
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the data, no more no less.
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be
Juha Manninen schrieb:
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the data, no more no less.
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be possible.
There is: there is no reason why move should be handled differently than other
procedures.
But currently move *does* handle
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storage.
But that has nothing to do with the fact that the
On 25 Apr 2010, at 17:38, Jürgen Hestermann wrote:
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be possible.
There is: there is no reason why move should be handled differently than
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal var parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true! There is a
I think there is a great difference between normal arrays and dynamic ones
Yes, but it should not be like that. If you first declare a static array and
then decide to make it a dynamic array then *no* code change should be
required. But now it is for move and fillchar.
is OK, but in
On 25 Apr 2010, at 18:24, Jürgen Hestermann wrote:
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal var parameter. Formal var parameters always take on the
address
True. As I said: There is no common logic what the identifier MyArray
means if it is a dynamic array (but there is for static arrays).
It means the whole array (which is an opaque type). No more no less.
Then it should be possible to use MyArray as a parameter for move/fillchar
but obviously
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal var parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true!
Well, it is.
Then it should be possible to use MyArray as a parameter for
move/fillchar but obviously this is not the case.
No. Because it does not mean the *array's data* but the *array*.
So it doesn't mean anything? What exactly is the *array* if not it's data?
On 25 Apr 2010, at 19:32, Jürgen Hestermann wrote:
There is a lot of ambigouity with dynamic arrays.
There certainly is if you expect them to work like regular arrays. They are
a quite different datatype.
At least it should always mean the same independent from context.
It does always
Jürgen Hestermann schrieb:
Then it should be possible to use MyArray as a parameter for
move/fillchar but obviously this is not the case.
No. Because it does not mean the *array's data* but the *array*.
So it doesn't mean anything? What exactly is the *array* if not it's data?
A variable
Hello FPC-Pascal,
Sunday, April 25, 2010, 6:29:26 PM, you wrote:
I think there is a great difference between normal arrays and dynamic ones
JH Yes, but it should not be like that. If you first declare a
JH static array and then decide to make it a dynamic array then *no*
JH code change should
Okay,
Since there hasn't been a clear response on this I've started my own
website, to start documenting more of the use of each library. However
doing so I am finding some clear issues, and that is some of these
units are not finished all the way. Is there some list of missing
functionality
On 25 April 2010 21:48, Joseph Montanez wrote:
Since there hasn't been a clear response on this I've started my own
website, to start documenting more of the use of each library.
The class documentation generated by fpdoc has support for examples.
FPC's policy is to only publish documentation
I don't see a benefit in having fragmented documentation over various
websites and locations. This makes it near impossible for a end-user to find
help.
The language itself is even worst, this is the biggest pitfall of
Pascal in general. I can't tell you how hard it is to find anything on
All the talk about the Pascal parser in fcl-passrc got me interested
recently. I did some experiments, and I thought I mention here:
1. I added a simplest example how to use fcl-passrc to the wiki:
http://wiki.freepascal.org/fcl-passrc
2. And reported a couple of bugs found in fpdoc (tested on
Florian Klaempfl wrote:
If you mess with move and have no clue about internals, then you get
burned. Period. Proper dyn. array code uses copy(...) instead of move.
I wish there was a type-checked equivalent to what move does. copy creates a
new
array, and I don't want to do that: I already
On 26/04/2010 8:23 AM, Joseph Montanez wrote:
snip
I would suggest you checkout the latest copy of the documentation
SubVersion repository:
http://svn.freepascal.org/svn/fpcdocs/trunk
Then submit code examples for the various units.
Are you seriously want everyone that wants to help
Dear FreePascal,
I have some questions when I am using Free Pascal
firstly , I find that I Can't use hot-key Ctrl+N to add
a new line in the IDE.
and I think the Free Pascal's ide is not very stable,
I am using fpc under a MS-DOS 7.1, sometimes when I am editing
my sourse code(I
25 matches
Mail list logo
