On 5/11/2021 4:09 AM, Ryan Joseph via fpc-devel wrote:
On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel
wrote:
You do not need any special language feature for that, you can simply do
something like
ReleaseLater(TObject.Create)
yes but we can't get back the reference.
> On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel
> wrote:
>
> You do not need any special language feature for that, you can simply do
> something like
>
>ReleaseLater(TObject.Create)
yes but we can't get back the reference. It's a small thing but making this
possible
On 5/8/2021 8:27 PM, Ryan Joseph via fpc-devel wrote:
That was a bad example. It's for ANY class really.
o := TObject.Create.AutoRelease;
Then next event cycle the autorelease pool frees all the objects added to it.
Very simple but effective however we can't do this in Pascal without a new
pe
> On May 8, 2021, at 8:05 AM, Sven Barth wrote:
>
>> a := TArray.Create([1,2,3]).AutoRelease;
>>
>> We can't do this in Pascal because the AutoRelease functions return type is
>> not compatible with the type of the caller. Could we add something like an
>> "Any" return type to Pascal which i
Am 07.05.2021 um 17:57 schrieb Ryan Joseph via fpc-devel:
On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel
wrote:
I cannot speak for others, but I think 90% of potential use cases for ref
counting
would be covered like this in my code: objects that only live inside a
procedure.
I think
Am 07.05.2021 um 17:40 schrieb Benito van der Zander via fpc-devel:
The introduction of generics and their abundant use in Delphi has
noticably slowed down the compiler and increased binary sizes. To my
dismay, compile times of 20 seconds up to 2 minutes have become not
uncommon in Delphi. Some
On 07/05/2021 07:26, Sven Barth via fpc-devel wrote:
> Trunk also supports POSIX exceptions on selected *nix based systems,
> though I haven't looked in depth yet in how far they incur a runtime
> penalty (also they need to be enabled by enabling them in the compiler
> and then recompiling everythi
On 07/05/2021 18:41, Ryan Joseph via fpc-devel wrote:
> Does that mean if you disable implicit exceptions then ALL ref counted types
> leak memory?
Only if an exception occurs.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://li
07.05.2021, 06:09, "Michael Van Canneyt via fpc-devel" :On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: I thought it was agreed at the time that this was the most viable way forward ? As far as I remember there wasn't really any agreement.Can be, I was not sure... I remember this path was inv
> On May 6, 2021, at 11:40 PM, Sven Barth wrote:
>
> There is no "finalization" section. It's really just an implicit try ...
> finally block that the compiler inserts. Look for "cs_implicit_exceptions"
> and "pi_needs_implicit_finally" if you want to learn more.
Does that mean if you disabl
> On May 7, 2021, at 9:40 AM, Benito van der Zander via fpc-devel
> wrote:
>
> the classic Delphi way was to use an interface for freeing. It only requires
> one type and nothing blows up.
>
That's clever but even try..finally is less overhead.
Regards,
Ryan Joseph
___
> On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel
> wrote:
>
> I cannot speak for others, but I think 90% of potential use cases for ref
> counting
> would be covered like this in my code: objects that only live inside a
> procedure.
>
> I think the same.
There's also a function which
Hi,
Don't forget that the record/management operator approach will again
blow up binary size; for every variable declared like this you risk
creating a new type.
the classic Delphi way was to use an interface for freeing. It only
requires one type and nothing blows up.
type
TDefer = c
> On May 7, 2021, at 3:08 AM, Michael Van Canneyt via fpc-devel
> wrote:
>
> The introduction of generics and their abundant use in Delphi has noticably
> slowed down the compiler and increased binary sizes. To my dismay, compile
> times of 20 seconds up to 2 minutes have become not uncommon
On Fri, 7 May 2021, Sven Barth via fpc-devel wrote:
I thought it was agreed at the time that this was the most viable way
forward ?
As far as I remember there wasn't really any agreement.
Can be, I was not sure... I remember this path was investigated.
IIRC there was also the proposal
Michael Van Canneyt via fpc-devel schrieb
am Fr., 7. Mai 2021, 08:14:
>
>
> On Fri, 7 May 2021, Sven Barth via fpc-devel wrote:
>
> >
> > In my opinion the better solution is to continue the road that Maciej
> > started and to implement that "default field" concept together with
> > operator hois
On Fri, 7 May 2021, Sven Barth via fpc-devel wrote:
In my opinion the better solution is to continue the road that Maciej
started and to implement that "default field" concept together with
operator hoistening so that records with management operators can be
used as containers. This is ess
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 s
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
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
count
> 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
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: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
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
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 wrote
> 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;
>
>
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 simpl
> 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 th
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 referen
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 hel
30 matches
Mail list logo