On 05 May 2010, at 18:21, Jürgen Hestermann wrote:
That's just the root cause of the problem
Another problem is that this thread has become too long and nobody is saying
anything new anymore. So please continue it on the fpc-other list.
Thanks,
Jonas
FPC mailing lists
José Mejuto het geskryf:
architectures. Much better would be move
(array1[0],array2[0],elements*sizeof(element)) but even in this case
the result is undefined, but it is a bit more exact as the programmer
Now this is a perfect example, of why I love Java (at least what I have
seen of it - I am
On Wed, May 5, 2010 at 07:34, Jürgen Hestermann
juergen.hesterm...@gmx.de wrote:
So why is it a problem, that one is a pointer, and the other not? Because
it is easier, or more often overlooked.
The problem is not that one is a pointer (to an array) and the other one is
the array itself. That
On Tue, 4 May 2010 23:49:00 +0200
José Mejuto joshy...@gmail.com wrote:
In computer science, an array data structure or simply array is a
data structure consisting of a collection of elements (values or
variables) [...]
???
What does this mean? As far as I know, variable in CS can have 3
From: Aleksa Todorovic on May 5, 2010 3:13:12 PM
As of copying/moving array elements, why don't you use
simple for loop
for that?
Because of performance optimization. TStringlist.Delete() and
TStringlist.InsertItem() itself uses Move() instead of such loop.
On Wed, 05 May 2010 07:34:41 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Say that it is a pointer to an array (and do not let the user think it is an
array!). And say that although it is a pointer you still cannot derefference
it but you need to use the first index to get the
Hello FPC-Pascal,
Wednesday, May 5, 2010, 8:54:01 AM, you wrote:
architectures. Much better would be move
(array1[0],array2[0],elements*sizeof(element)) but even in this case
the result is undefined, but it is a bit more exact as the programmer
GG Now this is a perfect example, of why I love
Hello FPC-Pascal,
Wednesday, May 5, 2010, 10:49:24 AM, you wrote:
In computer science, an array data structure or simply array is a
data structure consisting of a collection of elements (values or
variables) [...]
s ???
s What does this mean? As far as I know, variable in CS can
s have 3
Constants (values) or variable values (variables).
Let's not forget assignable constants that must be typed :-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 05/05/2010 06:34, Jürgen Hestermann wrote:
So why is it a problem, that one is a pointer, and the other not?
Because it is easier, or more often overlooked.
The problem is not that one is a pointer (to an array) and the other
one is the array itself. That would be fine if it is told to the
On Wed, 5 May 2010 13:44:40 +0200
José Mejuto joshy...@gmail.com wrote:
The same applies to Pascal, my previous example is badly designed, but
better than the first one. The problem here is try to use move as a
Pascal way of do things. Move is low level function that should be
used to
And as also explained in my original mail: An array does not guarantee
that the identifier(stand alone) can be used for the first element.
That's just the root cause of the problem: An idenifier should *always* mean
the same address in memory. Otherwise you cannot use such low level functions
I fear you've simply no clue about the usage,
internals and purpose of dyn. arrays so I stop this discussion.
As you always do once someone does not share your point of view, even after you
tried so hard to convince him. :P Well, never mind.
Still, dynamic arrays are a bitch, because they
Vinzent Höfler schrieb:
I fear you've simply no clue about the usage,
internals and purpose of dyn. arrays so I stop this discussion.
As you always do once someone does not share your point of view,
Indeed, because I don't want to waste too much of my fpc time with
writing useless emails.
On 5/4/2010 3:11 PM, Vinzent Höfler wrote:
The dynamic array simply fails the principle of least surprise. No
more, no less.
OK. You are correct. Now can we move on?
Doug C.
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A:
On 04/05/2010 20:11, Vinzent Höfler wrote:
I fear you've simply no clue about the usage,
internals and purpose of dyn. arrays so I stop this discussion.
As you always do once someone does not share your point of view, even after you
tried so hard to convince him. :P Well, never mind.
Hello FPC-Pascal,
Tuesday, May 4, 2010, 9:41:27 PM, you wrote:
M I have never found anything that says, that an array (not a
M static-array, just an array), always and under any circumstances must
M ensure that the identifier of the whole array is equal to the first
M data-element in the array?
So why is it a problem, that one is a pointer, and the other not?
Because it is easier, or more often overlooked.
The problem is not that one is a pointer (to an array) and the other one is the
array itself. That would be fine if it is told to the programmer that way and
if it would be
Jürgen Hestermann wrote:
Although I would have expected that special procedures exist to insert
and remove array elements so that there is no need to do such things
manually ...
David Emerson wrote:
These must be written on a case-by-case basis, for each type of array element.
Perhaps I'll
At best, one day we may add GPC-compatible array schema types (see
http://www.gnu-pascal.de/gpc/Schema-Types.html, the part under As a GNU
Pascal extension, the above can also be written as). These don't hide
anything.
Yes, that looks good as it does not violate the rule that an identifier
On 01 May 2010, at 11:09, Jürgen Hestermann wrote:
Yes, that looks good as it does not violate the rule that an identifier
should mean the same memory address independent from context.
As has been explained umpteen times already in this thread: a dynamic array
identifier always identifies
Jürgen Hestermann wrote:
Although I would have expected that special procedures exist to insert
and remove array elements so that there is no need to do such things
manually ...
These must be written on a case-by-case basis, for each type of array element.
Perhaps I'll tackle this someday as
I agree that the introduction of managed data types is inconsistent with
previous Pascal data types. Perhaps it is a design flaw to have changed
the semantics of reference-counted data types. Perhaps not.
Nevertheless, it has been this way for many, many years and will not be
changed at this
At least a file identifier always means the same memory address (where
the record data is stored). If needed (for some special purpose) I *can*
typecast it because I know the address of the data (@myfile). But when
using the identifier of a dynamic array then this identifier does not
always mean
Jürgen Hestermann wrote:
Where are the usage, internals and purpose of dyn. arrays documented?
I dunno. But I find them incredibly useful.
they have some quirks, and over the years I've been using dynarrays, I've
documented these on my own computer -- I even have a dynamic array test program
On 28 Apr 2010, at 08:05, Jürgen Hestermann wrote:
I am not sure whether this now cast in stone forever. Errors *can*
be corrected sometimes. ;-)
The behaviour of dynamic arrays will not be changed. At best, one day
we may add GPC-compatible array schema types (see
On 28 Apr 2010, at 10:48, Jonas Maebe wrote:
{ now delete one of these elements }
finalise(a[4]);
{ and compact the array }
move(a[3],a[4],(length(a)-3)*sizeof(a[0]));
Well, actually:
move(a[5],a[4],(length(a)-5)*sizeof(a[0]));
Jonas
___
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 mean the same, just like a class instance always means the
I dit not follow this thread, but maybe it helps.
Dynamic arrays are located on the heap and are reference counted.
The command System.Move will bypass the reference counting.
For this reason and to be sure the data is available when you need it
use System.Move on stack located arrays an
Jürgen Hestermann schrieb:
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 mean the same, just like a
On 4/27/2010 2:04 AM, Jürgen Hestermann wrote:
An identifier should always refer to a memory address/location. If the
type of the data at that memory location is a pointer then it should
be possible to change the expression to the memory address of the data
by dereferencing it with ^. But for
A file type is actually also a record and you cannot access the fields
without an explict type cast.
At least a file identifier always means the same memory address (where the
record data is stored). If needed (for some special purpose) I *can* typecast
it because I know the address of the
Jürgen Hestermann schrieb:
A file type is actually also a record and you cannot access the fields
without an explict type cast.
At least a file identifier always means the same memory address (where
the record data is stored). If needed (for some special purpose) I *can*
typecast it because
On 26 Apr 2010, at 03:27, David Emerson wrote:
It would be nice if move would give a compiler warning or note if it
receives a
pointer-pointer. I guess that would require move doing type-
checking... but at
compile-time, is there anything wrong with move doing such a type-
check and
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
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
I have a class that has a field,
f_data : array of byte; // a dynamic array
Within a method of this class (which takes as a parameter src, another
instance of the class) I have the following code:
move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte));
It appears that this move
2010/4/24 David Emerson dle...@angelbase.com:
move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte));
I think it should be:
SetLength(self.f_data, length(src.f_data));
move (src.f_data[0], self.f_data[0], length(self.f_data) * sizeof(byte));
--
cobines
cobines wrote:
David Emerson wrote:
move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte));
I think it should be:
SetLength(self.f_data, length(src.f_data));
move (src.f_data[0], self.f_data[0], length(self.f_data) * sizeof(byte));
Well, the setlength is not necessary, and
David,
I don't see how you are not getting memory leaks by doing a move
before making sure that the destination buffer has the memory
allocated. You see, in Delphi and FPC, move d/n actually move the
memory... It just copies it.
You were warned :-)
On Sat, Apr 24, 2010 at 3:01 PM, David
On 24/04/2010 22:01, Andrew Brunner wrote:
David,
I don't see how you are not getting memory leaks by doing a move
before making sure that the destination buffer has the memory
allocated. You see, in Delphi and FPC, move d/n actually move the
memory... It just copies it.
You were warned :-)
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]
On Sat 24 Apr 2010, Martin wrote:
On 24/04/2010 22:01, Andrew Brunner wrote:
David,
I don't see how you are not getting memory leaks by
59 matches
Mail list logo
