The reference count is only updated if the variable "A" was assigned to
another variable. However, if "A" was global, it may still be changed by a
second thread without changing its value.
program SwapTest;
uses
Classes, SysUtils;
type
{ MyThread }
MyThread = class(TThread)
protected
Hi,
Should "A" have a reference count of 1, and it is assigned a new value
on another thread, its reference count will decrease to zero and the
string and its descriptor are both freed. The value of "A" will be set
to nil.
If the reference count is 1, there is no other thread involved.
I
Your simplified code would not be thread safe. A thread swap after the
first instruction of
mov (%rdi), %rax
could potentially cause a problem. RAX (A) contains the pointer to the
string descriptor, which includes the pointer to the actual string data and
the reference count.
Should "A"
Hi,
Procedure ManagedMove(const source: T;var dest: T;count: SizeInt);
In principle a good idea. However this is one of those cases where
you'd definitely need to use constref instead of const.
Or var, since the source might be cleared
And perhaps there could be a special attribute
On Sun, Jan 10, 2021 at 12:09 PM Sven Barth via fpc-pascal
wrote:
> If after the Move only one of the two references is reachable anymore
> (because e.g. some internal count variable "ends" the array before that
> element) then you don't need to care about increasing the reference
> count, cause
Op 2021-01-11 om 15:26 schreef Benito van der Zander via fpc-pascal:
Hi,
perhaps a safe, generic function for this copying could be added to
the RTL. Like:
Procedure ManagedMove(const source: T;var dest: T;count: SizeInt);
a) For non-managed types it would be the same as Move(source, dest
On Sun, Jan 10, 2021 at 12:09 PM Sven Barth via fpc-pascal
wrote:
> If after the Move only one of the two references is reachable anymore
> (because e.g. some internal count variable "ends" the array before that
> element) then you don't need to care about increasing the reference
> count, cause
Benito van der Zander via fpc-pascal
schrieb am Mo., 11. Jan. 2021, 15:26:
> Hi,
>
> perhaps a safe, generic function for this copying could be added to the
> RTL. Like:
>
> Procedure ManagedMove(const source: T;var dest: T;count: SizeInt);
>
In principle a good idea. However this is one of tho
Hi,
perhaps a safe, generic function for this copying could be added to the
RTL. Like:
Procedure ManagedMove(const source: T;var dest: T;count: SizeInt);
a) For non-managed types it would be the same as Move(source, dest,
count*sizeof(T))
b) For reference counted types (like strings or i
Am 09.01.2021 um 18:23 schrieb Bart via fpc-pascal:
On Sat, Jan 9, 2021 at 5:12 PM Yuriy Sydorov via fpc-pascal
wrote:
2. Is it OK if the elements of the array are (or contain) managed types?
You need to manually finalize/free elements which are overwritten before
calling Move.
So, if I mov
Am 09.01.2021 um 22:54 schrieb Bart via fpc-pascal:
On Sat, Jan 9, 2021 at 8:14 PM Yuriy Sydorov via fpc-pascal
wrote:
So, I'll use a for loop to copy the data.
I assume that doing Arr[Index] := Default(T) will also finalize the
element if that element ismanaged?
For class object instances c
For checking if it's a managed type you should use the IsManagedType
intrinsic.
You could also use it to implement the System.Move() for non-managed types.
The compiler only generates the appropriate code:
If IsManagedType(T) then
// for loop
else
// move
Best Regards
Nico
Bart via fpc-pasca
On Sat, Jan 9, 2021 at 8:14 PM Yuriy Sydorov via fpc-pascal
wrote:
> > So, I'll use a for loop to copy the data.
> >
> > I assume that doing Arr[Index] := Default(T) will also finalize the
> > element if that element ismanaged?
>
> For class object instances call Arr[Index].Free, for other manage
Op 2021-01-09 om 20:12 schreef Yuriy Sydorov via fpc-pascal:
So, if I move Arr[3] to Arr[1], I first have to finilize/free Arr[1].
After that move the bytes in Arr[3] are exactly the same as in Arr[1]
(by definition of how move works) AFAIU.
Is that a problem with refcounts, because they would
On 09.01.2021 19:23, Bart via fpc-pascal wrote:
On Sat, Jan 9, 2021 at 5:12 PM Yuriy Sydorov via fpc-pascal
wrote:
2. Is it OK if the elements of the array are (or contain) managed types?
You need to manually finalize/free elements which are overwritten before
calling Move.
So, if I move A
On Sat, Jan 9, 2021 at 5:12 PM Yuriy Sydorov via fpc-pascal
wrote:
> > 2. Is it OK if the elements of the array are (or contain) managed types?
>
> You need to manually finalize/free elements which are overwritten before
> calling Move.
So, if I move Arr[3] to Arr[1], I first have to finilize/fr
On 09.01.2021 17:28, Bart via fpc-pascal wrote:
This may be a silly question.
I use System.Move() to move items in a dynamic array, like
Move(FData[0], FData[OldEnd], FStart*SizeOf(T));
Where T is the type of the elements in the array.
This seems to work as expected.
I have some questions tho
Hi,
This may be a silly question.
I use System.Move() to move items in a dynamic array, like
Move(FData[0], FData[OldEnd], FStart*SizeOf(T));
Where T is the type of the elements in the array.
This seems to work as expected.
I have some questions though:
1. Does this depend on the alignment of
18 matches
Mail list logo
