Re: [fpc-pascal] Freeing memory with exceptions
On Wed, 24 May 2023, Hairy Pixels via fpc-pascal wrote: On May 21, 2023, at 11:03 PM, Michael Van Canneyt via fpc-pascal wrote: They're used all over the place in the RTL and FCL, so you better take them into account. The compiler will do this wrapping anyway if you use ansistrings, so the approach with e.g. a generic record will not cause a lot of overhead in most cases. I wanted to add to my example. What about this? The exception now provides a challenge to clean up without ARC in all places. Very risky right? My sense is that exceptions are only safe for fully ARC languages or garbage collected. I see no problem, I am used to this. This is Pascal, you need to manage your memory and hence your references, this is true even in the absence of exceptions: In your example you would also need to remember to remove your instance from the list after you free it, even if there are no exceptions. That is why I usually use TComponent as a base class. It has an owner-owned concept and when you free the toplevel component, all children are also freed. It also has a "free notification" mechanism: when a referenced object is freed, you can get notified and can take appropriate action. If you use that correctly, there is very little to worry about. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
> On May 21, 2023, at 11:03 PM, Michael Van Canneyt via fpc-pascal > wrote: > > They're used all over the place in the RTL and FCL, so you better take them > into account. > > The compiler will do this wrapping anyway if you use ansistrings, so the > approach with e.g. a generic record will not cause a lot of overhead in most > cases. I wanted to add to my example. What about this? The exception now provides a challenge to clean up without ARC in all places. Very risky right? My sense is that exceptions are only safe for fully ARC languages or garbage collected. var obj: TObject; begin try obj := TObject.Create; // This object list will free the items in another part of the program if CheckSomething(...) then begin list.Add(obj); addedToList := true; end; // maybe we passed it to another class also... // Raises an exception in another unit, caller doesn't know! DoThis; finally // we need to remember to remove the item from the list now and // what happens if we passed the reference to another class? // we need to check if this actually happened also so declare a local var to check if addedToList then list.Delete(..); if passedToOtherClass then otherClass.obj := nil; obj.Free; end; end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Hairy Pixels via fpc-pascal schrieb am Mi., 24. Mai 2023, 14:10: > You must have $H+ on and those are AnsiStrings? Why is there exception > handling involved with AnsiString? I guess it needs this just in case an > exception is thrown somewhere in the call stack? Because Ansi- and UnicodeString are managed types. *All* managed types managed string types, interfaces, Variants, managed records) must be finalized correctly even if an exception occurs. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
On 23-5-2023 12:44, Benito van der Zander via fpc-pascal wrote: Hi, Depends on your code. I wrote all my code in Delphi 4. From 1998 or so. I do not make new projects, only maintain old ones. Delphi 4 felt much better. Like take: procedure test; var s: string; begin s:= 'abc'; end; It is weird that your code calls setjmp? Are you using a non Windows platform? Comparisons with Delphi should be done on Windows where the exception systems match. Apples to Apples please. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Hi, It is weird that your code calls setjmp? Are you using a non Windows platform? Comparisons with Delphi should be done on Windows where the exception systems match. Apples to Apples please. It is FPC on Linux. And Delphi 4 on Linux (in WINE) Even if it wants to do the Linux nonsense, FPC could at least inline fpc_setjmp in fpc_pushexceptaddr to make it only one function call. I regret installing Linux. Everything worked better with Windows 98 and Delphi 4 Sincerely, Benito On 24.05.23 10:14, Marco van de Voort via fpc-pascal wrote: On 23-5-2023 12:44, Benito van der Zander via fpc-pascal wrote: Hi, Depends on your code. I wrote all my code in Delphi 4. From 1998 or so. I do not make new projects, only maintain old ones. Delphi 4 felt much better. Like take: procedure test; var s: string; begin s:= 'abc'; end; It is weird that your code calls setjmp? Are you using a non Windows platform? Comparisons with Delphi should be done on Windows where the exception systems match. Apples to Apples please. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Benito van der Zander via fpc-pascal schrieb am Mi., 24. Mai 2023, 13:00: > Hi, > > It is weird that your code calls setjmp? Are you using a non Windows > platform? Comparisons with Delphi should be done on Windows where the > exception systems match. Apples to Apples please. > > > It is FPC on Linux. > > And Delphi 4 on Linux (in WINE) > As Marco said, please compare using the same *target* platform otherwise you're comparing apples with oranges due to different exception handling mechanisms between Windows and Linux. > > Even if it wants to do the Linux nonsense, FPC could at least inline > fpc_setjmp in fpc_pushexceptaddr to make it only one function call. > fpc_setjmp can not be unlined because a) it's an assembly function and b) *relies* on being a separate function. And fpc_pushexceptaddr not only accesses private state of the system unit, it's also a larger function and thus inlining it would not provide any benefit. Also combining them would not work, because they are for different purposes. The low level exception handling code is the way it is for reasons. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
You must have $H+ on and those are AnsiStrings? Why is there exception handling involved with AnsiString? I guess it needs this just in case an exception is thrown somewhere in the call stack? > On May 23, 2023, at 5:44 PM, Benito van der Zander via fpc-pascal > wrote: > > Like take: > > procedure test; > var s: string; > begin > s:= 'abc'; > end; > Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
On 24-5-2023 13:00, Benito van der Zander via fpc-pascal wrote: It is weird that your code calls setjmp? Are you using a non Windows platform? Comparisons with Delphi should be done on Windows where the exception systems match. Apples to Apples please. It is FPC on Linux. And Delphi 4 on Linux (in WINE) Then also run FPC/win32 in wine for a real comparison. Even if it wants to do the Linux nonsense, FPC could at least inline fpc_setjmp in fpc_pushexceptaddr to make it only one function call. I regret installing Linux. Everything worked better with Windows 98 and Delphi 4 These kinds of statements are counter-productive. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
> On May 24, 2023, at 8:46 PM, Michael Van Canneyt via fpc-pascal > wrote: > > I see no problem, I am used to this. > > This is Pascal, you need to manage your memory and hence your references, > this is true even in the absence of exceptions: In your example you would > also need to remember to remove your instance from the list after you free > it, even if there are no exceptions. My example is still not good. The problem I have is that once exceptions are used in a program calling any function now has a side effect of completely exiting the calling function so you need to be paranoid and wrap everything in try blocks just in case. A new added burden for manual memory management. Why is this better than handling errors as values like a normal function result? Rust is maybe the most major language which has not implemented exceptions but I'm seeing other new experimental languages go this way also. I've only used them in C# and Swift which are fully ARC but they appear to be a bad idea the industry is going against now after years of experience. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Hairy Pixels via fpc-pascal schrieb am Do., 25. Mai 2023, 04:26: > > > > On May 24, 2023, at 10:11 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > You must have $H+ on and those are AnsiStrings? Why is there exception > handling involved with AnsiString? I guess it needs this just in case an > exception is thrown somewhere in the call stack? > > > > Because Ansi- and UnicodeString are managed types. *All* managed types > managed string types, interfaces, Variants, managed records) must be > finalized correctly even if an exception occurs. > > > > That's a problem with exceptions then, they are baked into the language > and impose a cost on all managed types now even if we use them or not. Even > disabling the implicit stack frames (forgot what it's called) doesn't get > around this right? > Disabling implicit exception frames does exactly what it says in the tin and removes these automatically generated frames. This however opens you to potential memory leaks if an exception occurs, so one should think twice whether one uses this option. Thankfully it's a local directive, so one can make this choice for every function. But this is what "managed type" *means*: that the compiler and RTL will make sure that it's correctly freed as long as nothing unexpected happens. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
> On May 24, 2023, at 10:11 PM, Sven Barth via fpc-pascal > wrote: > > You must have $H+ on and those are AnsiStrings? Why is there exception > handling involved with AnsiString? I guess it needs this just in case an > exception is thrown somewhere in the call stack? > > Because Ansi- and UnicodeString are managed types. *All* managed types > managed string types, interfaces, Variants, managed records) must be > finalized correctly even if an exception occurs. > That's a problem with exceptions then, they are baked into the language and impose a cost on all managed types now even if we use them or not. Even disabling the implicit stack frames (forgot what it's called) doesn't get around this right? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
On Thu, 25 May 2023, Hairy Pixels via fpc-pascal wrote: On May 24, 2023, at 10:11 PM, Sven Barth via fpc-pascal wrote: You must have $H+ on and those are AnsiStrings? Why is there exception handling involved with AnsiString? I guess it needs this just in case an exception is thrown somewhere in the call stack? Because Ansi- and UnicodeString are managed types. *All* managed types managed string types, interfaces, Variants, managed records) must be finalized correctly even if an exception occurs. That's a problem with exceptions then, they are baked into the language and impose a cost on all managed types now even if we use them or not. Even disabling the implicit stack frames (forgot what it's called) doesn't get around this right? Why do you insist it is a problem ? Simply don't use managed types and don't use exceptions if you don't like the overhead they cause. It's still perfectly possible: avoid the sysutils unit and you're all set. The system unit does not use exceptions. That 99.99% of people does use it, indicates they simply take the overhead because of the advantages that the managed types offer. Which is not to say that FPC should not strive to minimize the overhead. Conceivably there is some gain possible on non-windows platforms. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Benito van der Zander via fpc-pascal schrieb am Do., 25. Mai 2023, 00:15: > Hi > > > Then also run FPC/win32 in wine for a real comparison. > > > Or perhaps against modern C++ on Linux would also be a real comparison > It wouldn't be, because that would compare two different languages. C++ doesn't have a concept of resource protection blocks like Object Pascal has. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freeing memory with exceptions
Hi Then also run FPC/win32 in wine for a real comparison. Or perhaps against modern C++ on Linux would also be a real comparison FPC could at least inline fpc_setjmp in fpc_pushexceptaddr to make it only one function call. These kinds of statements are counter-productive. That is a very productive optimization idea Cheers, Benito On 24.05.23 13:10, Marco van de Voort via fpc-pascal wrote: On 24-5-2023 13:00, Benito van der Zander via fpc-pascal wrote: It is weird that your code calls setjmp? Are you using a non Windows platform? Comparisons with Delphi should be done on Windows where the exception systems match. Apples to Apples please. It is FPC on Linux. And Delphi 4 on Linux (in WINE) Then also run FPC/win32 in wine for a real comparison. Even if it wants to do the Linux nonsense, FPC could at least inline fpc_setjmp in fpc_pushexceptaddr to make it only one function call. I regret installing Linux. Everything worked better with Windows 98 and Delphi 4 These kinds of statements are counter-productive. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
