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 admin
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
On Wed, 5 May 2010 13:44:40 +0200
José Mejuto 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 optimize code when y
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, 05 May 2010 07:34:41 +0200
Jürgen Hestermann 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 beginning of the array.
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 Tue, 4 May 2010 23:49:00 +0200
José Mejuto 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 senses,
depending
On Wed, May 5, 2010 at 07: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 i
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 -
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 consist
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.
S
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:
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 ema
> 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 on
>>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.
>Perhap
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
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
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 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
___
fpc-
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 http://www.gnu-pascal.d
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
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 t
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 po
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
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 dat
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 d
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,
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 strings
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
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
issuing
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 h
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
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 a
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?
___
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.
Jürgen Hestermann schrieb:
>>> 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 p
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 obvious
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 th
Jürgen Hestermann schrieb:
>
>
>>> 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 whatev
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 dynamic
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
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
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 identifier
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 d
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 fundam
> 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 possibl
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 storag
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:
>> 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 pr
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 synt
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 leak
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 :-)
O
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 Emerson
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
2010/4/24 David Emerson :
> 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
___
55 matches
Mail list logo
