Hi,
07.05.2021 1:32, Ryan Joseph via fpc-devel:
[...]
it's kind of frustrating that we have ref counted types but that isn't extended
to classes.
Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles, which then cause damage to ref
> On May 6, 2021, at 7:14 PM, Ryan Joseph wrote:
>
> This can be detected at compile and at least give a warning. "a" is a member
> of TR and the element type of "a" is TR, then we're assigning TR to said
> array. It's that simple I think.
It also occurs to me that record management
Am 07.05.2021 um 00:32 schrieb Ryan Joseph via fpc-devel:
On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel
wrote:
There is a performance penalty when using them, which one reason why the
compiler sources don't use them. There's probably other reasons too. There
might be some
On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote:
Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles,
You can already cause ref circles, no classes needed.
type
TR = record
a: array of TR;
end;
var
x: TR;
begin
Am 07.05.2021 um 00:17 schrieb Ryan Joseph via fpc-devel:
On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel
wrote:
Other than that, you're right and what Ryan is trying to do is definitely the
intended purpose of try ... finally.
Is there any runtime code involved with try..finally or
> On May 6, 2021, at 5:41 PM, Martin Frb via fpc-devel
> wrote:
>
> You can already cause ref circles, no classes needed.
>
> type
> TR = record
> a: array of TR;
> end;
>
> var
> x: TR;
> begin
> SetLength(x.a,99);
> x.a[0] := x;
> end.
This can be detected at compile and at
Hi Martin,
07.05.2021 2:41, Martin Frb via fpc-devel:
On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote:
Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles,
You can already cause ref circles, no classes needed.
Yes, records and
I found something sneaky I'd like to confirm before I decide what to do about
it.
1) "T" in TAnyClass is specialized as Integer from the first parameter with
TSomeClass (which is TAnyClass).
2) "U" is getting specialized as String by looking at the parameters in
Compare() in which "U"(the
Op 2021-05-06 om 17:38 schreef Ryan Joseph via fpc-devel:
Something which annoys me about Pascal is cleanup in which a function exits in multiple
places but there is no formal way to free memory which may be used in the current scope.
I say ultimately Pascal needs some opt-in automatic
> On May 6, 2021, at 11:39 AM, J. Gareth Moreton via fpc-devel
> wrote:
>
> In the example given:
>
> obj := TObject.Create;
> defer objects.Free;
>
> What's wrong with Pascal's existing functionality?
>
> obj := TObject.Create;
> try
>...
> finally
>objects.Free;
> end;
>
>
Something which annoys me about Pascal is cleanup in which a function exits in
multiple places but there is no formal way to free memory which may be used in
the current scope. I say ultimately Pascal needs some opt-in automatic
reference counting for TObject but the "defer" keyword would be
The rule with try...finally is that, outside of something completely
catastrophic that destroys the program flow, is that once you enter the
try part, the finally part is guaranteed to be executed no matter how
you leave it.
Gareth aka. Kit
On 06/05/2021 18:53, Ryan Joseph via fpc-devel
> On May 6, 2021, at 10:44 AM, Marco van de Voort via fpc-devel
> wrote:
>
> But those types have refcounting built-in and always active. Things like
> defer don't, which makes that all objects gets refcounting overhead in case
> somebody needs it for "defer".
>
> Contrary to Pascal both
In the example given:
obj := TObject.Create;
defer objects.Free;
What's wrong with Pascal's existing functionality?
obj := TObject.Create;
try
...
finally
objects.Free;
end;
If there's a concern about performance penalty, maybe the compiler can
work something out for
J. Gareth Moreton via fpc-devel schrieb am
Do., 6. Mai 2021, 20:03:
> The rule with try...finally is that, outside of something completely
> catastrophic that destroys the program flow, is that once you enter the
> try part, the finally part is guaranteed to be executed no matter how
> you leave
> On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel
> wrote:
>
> Other than that, you're right and what Ryan is trying to do is definitely the
> intended purpose of try ... finally.
>
Is there any runtime code involved with try..finally or does it just reorganize
the code to run at the
There is some special handling involved in that the code inside the try
part (I think) is effectively a nested procedure. It's important in the
context of stack unwinding when an exception occurs. There is a
performance penalty when using them, which one reason why the compiler
sources don't
> On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel
> wrote:
>
> There is a performance penalty when using them, which one reason why the
> compiler sources don't use them. There's probably other reasons too. There
> might be some speed-up potential where standard Exit calls are
18 matches
Mail list logo
