On 02/17/2014 09:10 PM, Florian Klämpfl wrote:
Am 16.02.2014 17:16, schrieb Michael Van Canneyt:
2) SetLength enforces unique ref. count.
I'am against stating this in the docs. It is an implementation detail.
Moreover this would ask for a long winding explanation what "unique ref
count" exactl
Am 17.02.2014 21:09, schrieb Florian Klämpfl:
Am 16.02.2014 14:07, schrieb Jürgen Hestermann:
When using unknown features of a programming language for the first time
then the documentaion should tell all aspects in detail and describe the
exact behaviour.
No. Details might be implementation sp
In our previous episode, Martin Frb said:
> >> the array), does not mean there is copy on write.
> > So basically, if for a given size x, setlength(x,1) always reallocates, then
> > it is COW, otherwise not :-)
That came out wrong wrong. Should've been for given x, setlength(p,x+1); p
(after) is
On 17/02/2014 20:10, Florian Klämpfl wrote:
Am 16.02.2014 17:16, schrieb Michael Van Canneyt:
2) SetLength enforces unique ref. count.
I'am against stating this in the docs. It is an implementation detail.
The proper way to do a deep copy is using copy.
IMHO, it must be documented, even if it
Am 16.02.2014 17:16, schrieb Michael Van Canneyt:
> 2) SetLength enforces unique ref. count.
I'am against stating this in the docs. It is an implementation detail.
The proper way to do a deep copy is using copy.
___
fpc-pascal maillist - fpc-pascal@lis
Am 16.02.2014 14:07, schrieb Jürgen Hestermann:
> When using unknown features of a programming language for the first time
> then the documentaion should tell all aspects in detail and describe the
> exact behaviour.
No. Details might be implementation specific behaviour which might change.
_
On 17/02/2014 19:50, Jonas Maebe wrote:
On 17 Feb 2014, at 20:41, Martin Frb wrote:
"Dynamic arrays have no copy-on-write. But SetLength perform a copy-on-write on
dynamic arrays."
I am not sure, if that makes to much sense either
It doesn't, because even if you don't change the length it ma
On 17 Feb 2014, at 20:41, Martin Frb wrote:
> "Dynamic arrays have no copy-on-write. But SetLength perform a copy-on-write
> on dynamic arrays."
>
> I am not sure, if that makes to much sense either
It doesn't, because even if you don't change the length it makes a unique copy.
Jonas
___
On 17/02/2014 19:34, Marco van de Voort wrote:
In our previous episode, Martin Frb said:
Just because there is a function, that includes copying (when modifying
the array), does not mean there is copy on write.
So basically, if for a given size x, setlength(x,1) always reallocates, then
it is C
In our previous episode, Martin Frb said:
> Just because there is a function, that includes copying (when modifying
> the array), does not mean there is copy on write.
So basically, if for a given size x, setlength(x,1) always reallocates, then
it is COW, otherwise not :-)
(and even if it does,
On 17/02/2014 18:19, Jürgen Hestermann wrote:
Am 2014-02-17 18:49, schrieb Martin Frb:
Then why does this discussion continue, now that it is documented?
Does it matter what other people consider a write and what not?
(Unless that part made it into the docs, but there was no mention it
did)?
On 17 Feb 2014, at 19:19, Jürgen Hestermann wrote:
> And I have not seen what change was made to the documentation.
svn co http://svn.freepascal.org/svn/fpcdocs/trunk
It's the same as when something is fixed in FPC: this does not change anything
to the latest release, which is what's available
Am 2014-02-17 18:49, schrieb Martin Frb:
Then why does this discussion continue, now that it is documented?
Does it matter what other people consider a write and what not? (Unless that
part made it into the docs, but there was no mention it did)?
Of course it would not matter if it wasn't par
On 17/02/2014 17:28, Jürgen Hestermann wrote:
Am 2014-02-17 18:01, schrieb Martin Frb:
> On 17/02/2014 16:40, Jürgen Hestermann wrote:
> It appears, that the copy-on-setlength is intended. So in that the
documentation is right.
It is intended but is was not mentioned in the documentation.
Ther
Am 2014-02-17 18:01, schrieb Martin Frb:
> On 17/02/2014 16:40, Jürgen Hestermann wrote:
> It appears, that the copy-on-setlength is intended. So in that the
documentation is right.
It is intended but is was not mentioned in the documentation.
Therefore this whole thread exists at all.
> As fo
On 17/02/2014 16:40, Jürgen Hestermann wrote:
But changing the size it is a modification! When an array can be
resized then the resizing means that I have to write to it (in
contrast to reading, where no data is modified). I am astonished that
everybody here seems not to see this. Maybe becau
On 17/02/2014 16:40, Jürgen Hestermann wrote:
Am 2014-02-17 10:38, schrieb Lukasz Sokol:
> To 'write' usually means : changing DATA element(s). That's it.
What else is it when adding or removing elements? The array is
modified. That can only mean it was written to it.
> SetLength is /not/ a
Am 2014-02-17 10:38, schrieb Lukasz Sokol:
> To 'write' usually means : changing DATA element(s). That's it.
What else is it when adding or removing elements? The array is modified. That
can only mean it was written to it.
> SetLength is /not/ a write in this sense : because you're resizing th
On 17/02/14 09:51, Michael Van Canneyt wrote:
>
>
> On Mon, 17 Feb 2014, Lukasz Sokol wrote:
>
>> On 17/02/14 06:02, Jürgen Hestermann wrote:
>>>
>>> Am 2014-02-16 17:16, schrieb Michael Van Canneyt:
It does exactly that, it says:
1) No COW
>>>
>>> As said already: SetLength *is* a wri
On Mon, 17 Feb 2014, Lukasz Sokol wrote:
On 17/02/14 06:02, Jürgen Hestermann wrote:
Am 2014-02-16 17:16, schrieb Michael Van Canneyt:
It does exactly that, it says:
1) No COW
As said already: SetLength *is* a write!
I'm not of compiler background - but I think you're confusing things
On 17/02/14 06:02, Jürgen Hestermann wrote:
>
> Am 2014-02-16 17:16, schrieb Michael Van Canneyt:
>> It does exactly that, it says:
>> 1) No COW
>
> As said already: SetLength *is* a write!
>
>
I'm not of compiler background - but I think you're confusing things here.
To 'write' usually means
Am 2014-02-16 17:16, schrieb Michael Van Canneyt:
It does exactly that, it says:
1) No COW
As said already: SetLength *is* a write!
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc
On Sun, 16 Feb 2014, Jürgen Hestermann wrote:
Am 2014-02-16 13:47, schrieb Florian Klämpfl:
setlength does not behave freaky but its behaviour is well designed. The
reason why setlength does a deep copy is simple: multithreading. If
setlength had no deep copy semantics, it would need locking
Am 2014-02-16 13:47, schrieb Florian Klämpfl:
> setlength does not behave freaky but its behaviour is well designed. The
> reason why setlength does a deep copy is simple: multithreading. If
> setlength had no deep copy semantics, it would need locking of the whole
> array data, not only locked ac
Am 2014-02-16 13:20, schrieb Michael Van Canneyt:
> Depends on how you define 'write to the array'.
> "Writing to the array" = "Changing the value of one of the elements in the
array."
> In this sense, setlength does not write to the array, which would mean
changing the value of
> one or more of
Am 15.02.2014 19:41, schrieb Michael Van Canneyt:
>
> That setlength behaves rather freakish for dynamic arrays, does not
> mean we have copy-on-write.
setlength does not behave freaky but its behaviour is well designed. The
reason why setlength does a deep copy is simple: multithreading. If
setl
On Sun, 16 Feb 2014, Jürgen Hestermann wrote:
Am 2014-02-15 19:41, schrieb Michael Van Canneyt:
That setlength behaves rather freakish for dynamic arrays, does not mean we
have copy-on-write.
Well, setlength *is* a write.
What else is it?
Doesn't it write to the array?
Depends on how you
Am 2014-02-15 19:41, schrieb Michael Van Canneyt:
That setlength behaves rather freakish for dynamic arrays, does not mean we
have copy-on-write.
Well, setlength *is* a write.
What else is it?
Doesn't it write to the array?
___
fpc-pascal maillist
On Sat, 15 Feb 2014, Jürgen Hestermann wrote:
Am 2014-02-10 09:13, schrieb Michael Van Canneyt:
No. There is no COW, only ref. counting. SetLength just forces an unique
instance of the array if needed.
The documentation explicitly mentions that:
'Dynamic arrays are reference counted: assignm
Am 2014-02-10 09:13, schrieb Michael Van Canneyt:
>> No. There is no COW, only ref. counting. SetLength just forces an unique
>> instance of the array if needed.
> The documentation explicitly mentions that:
> 'Dynamic arrays are reference counted: assignment of one dynamic array-type
> variable t
Am 2014-02-09 19:29, schrieb Florian Klämpfl:
> Am 09.02.2014 18:41, schrieb Jürgen Hestermann:
>> So it seems there is a copy-on-write *but* only when using SetLength.
> No. There is no COW, only ref. counting. SetLength just forces an unique
> instance of the array if needed.
But this *is* Copy
On Sun, 9 Feb 2014, Florian Klämpfl wrote:
Am 09.02.2014 18:41, schrieb Jürgen Hestermann:
So it seems there is a copy-on-write *but* only when using SetLength.
No. There is no COW, only ref. counting. SetLength just forces an unique
instance of the array if needed.
The documentation expl
On 09.02.2014 19:10, patspiper wrote:
On 09/02/14 18:47, Sven Barth wrote:
On 09.02.2014 16:34, Flávio Etrusco wrote:
In other words: dynamic arrays are like AnsiStrings without the
copy-on-write semantics. I'd certainly wish Borland copied the COW
semantics :-/
Dynamic arrays have full COW
Am 09.02.2014 18:41, schrieb Jürgen Hestermann:
> So it seems there is a copy-on-write *but* only when using SetLength.
No. There is no COW, only ref. counting. SetLength just forces an unique
instance of the array if needed.
> What a very consistent design!
There is a very good reason for this
On 09/02/14 18:47, Sven Barth wrote:
On 09.02.2014 16:34, Flávio Etrusco wrote:
In other words: dynamic arrays are like AnsiStrings without the
copy-on-write semantics. I'd certainly wish Borland copied the COW
semantics :-/
Dynamic arrays have full COW semantics.
It seems not:
SetLength
Am 2014-02-09 17:47, schrieb Sven Barth:
On 09.02.2014 16:34, Flávio Etrusco wrote:
In other words: dynamic arrays are like AnsiStrings without the
copy-on-write semantics. I'd certainly wish Borland copied the COW
semantics :-/
Dynamic arrays have full COW semantics.
Now I am fully confus
Am 2014-02-09 16:34, schrieb Flávio Etrusco:
> In other words: dynamic arrays are like AnsiStrings without the
> copy-on-write semantics. I'd certainly wish Borland copied the COW
> semantics :-/
Yes. Therefore the issue that I described for dynamic arrays cannot occur for
ansistrings. But COW c
On 09.02.2014 16:34, Flávio Etrusco wrote:
In other words: dynamic arrays are like AnsiStrings without the
copy-on-write semantics. I'd certainly wish Borland copied the COW
semantics :-/
Dynamic arrays have full COW semantics. If Jürgen would have provided a
full compilable example we could
On 09.02.2014 15:34, Jürgen Hestermann wrote:
With the following declaration and code:
---
var A,B: array of integer;
...
SetLength(A,10);
B := A;
SetLength(B,20);
---
both variables A and B point to the same array with 20 Elements.
Changing A changes B and vice
On Sun, Feb 9, 2014 at 12:34 PM, Jürgen Hestermann
wrote:
> (...)
> With the following declaration and code:
>
> ---
> var A,B: array of integer;
> ...
> SetLength(A,10);
> B := A;
> SetLength(B,20);
> ---
>
> both variables A and B point to the same array with 20 E
There is another possible pitfall with dynamic arrays I trapped into which I
would like to share.
Those who handle dynamic arrays in a virtuoso manner daily may skip this
posting of course.
But I think for those who never used them before it may be of use.
Maybe it can be added to the Wiki (alth
41 matches
Mail list logo
