Re: [fpc-pascal] Freeing memory with exceptions
Steve Litt via fpc-pascal schrieb am Di., 30. Mai 2023, 21:57: > I don't know about other operating systems, but on Linux a crashed > program gives up all its memory, even leaked memory, upon termination, > so I'm not sure why this attention to memory leak on abnormal > termination is even necessary. > An exception does not have to end with the program's termination. And if the program does not terminate due to an exception it makes sense to avoid memory leaks as the program might be long running. 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
Michael Van Canneyt via fpc-pascal said on Tue, 30 May 2023 16:55:16 +0200 (CEST) >On Tue, 30 May 2023, Hairy Pixels via fpc-pascal wrote: > >> >> >>> On May 25, 2023, at 1:10 PM, Michael Van Canneyt via fpc-pascal >>> wrote: >>> >>> >>> In C you need to do something like this: >>> >>> Function MyFunction(out theresult : TResultType) : Integer; >>> >>> begin >>> Allocate A >>> ... >>> error condition 1: >>>Free A, exit (1); >>> ... >>> Allocate B >>> error condition 2: >>>Free A, Free B, exit(2) >>> >>> Allocate C >>> error condition 3: >>> Free A, Free B, free C, exit(3); >>> ... >>> // etc >>> // All went well, report 0 >>> theresult:=X; >>> Free A, Free B, free C exit(0); >>> end. >> >> Indeed this is an ideal example of why they were invented and it >> makes sense here. Honestly most of this mess could be cleaned up >> with smart pointers also and not upset control flow like exceptions >> do. >> >> I'm doing work with Swift right now and in particular a web >> framework that makes lots of database calls, all of which can fail >> so we use exceptions everywhere. The thing that Swift does well and >> FPC does not, is that it labels the functions as "throws" and calls >> have a "try" keyword before them so you know how the control flow is >> actually working. >> >> Because FPC doesn't do this any function could throw errors and thus >> those stack frames are inserted everywhere and add needless overhead >> when exceptions aren't used. It's also nice to not have hidden >> control flow potential on any function call > >The rule is simple in FPC: You should always assume exceptions >everywhere. > >Simply because system errors are also transformed to exceptions, and >thus any function can indeed throw errors: > >an "Access Violation" error can happen on any level of the code, >or an "out of memory" or some other signal by the system or even CPU >(think overflow). > >If sysutils is used, these are transformed to an exception, regardless >of whether the code itself uses exceptions to report errors or not. > >The only way to know for sure there will not be an exception is not to >use sysutils anywhere in your code or anyone elses code. > >Delphi introduced a coupling between sysutils and exceptions, and now >we're stuck with that. > >Today, you'd need to write your RTL to get rid of them. > >Michael. Would this work?... Have a global self-kill object containing a list of every object that's been allocated. After every successful allocation, call the self-kill object method to add the object onto the list. On every successful free, call self-kill method to remove that object from the list. On programmer-defined exceptions, call self-kill's method to free everything on the list and then free itself, after which the program can terminate. I don't know about other operating systems, but on Linux a crashed program gives up all its memory, even leaked memory, upon termination, so I'm not sure why this attention to memory leak on abnormal termination is even necessary. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm ___ 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 Tue, 30 May 2023, Hairy Pixels via fpc-pascal wrote: On May 25, 2023, at 1:10 PM, Michael Van Canneyt via fpc-pascal wrote: In C you need to do something like this: Function MyFunction(out theresult : TResultType) : Integer; begin Allocate A ... error condition 1: Free A, exit (1); ... Allocate B error condition 2: Free A, Free B, exit(2) Allocate C error condition 3: Free A, Free B, free C, exit(3); ... // etc // All went well, report 0 theresult:=X; Free A, Free B, free C exit(0); end. Indeed this is an ideal example of why they were invented and it makes sense here. Honestly most of this mess could be cleaned up with smart pointers also and not upset control flow like exceptions do. I'm doing work with Swift right now and in particular a web framework that makes lots of database calls, all of which can fail so we use exceptions everywhere. The thing that Swift does well and FPC does not, is that it labels the functions as "throws" and calls have a "try" keyword before them so you know how the control flow is actually working. Because FPC doesn't do this any function could throw errors and thus those stack frames are inserted everywhere and add needless overhead when exceptions aren't used. It's also nice to not have hidden control flow potential on any function call The rule is simple in FPC: You should always assume exceptions everywhere. Simply because system errors are also transformed to exceptions, and thus any function can indeed throw errors: an "Access Violation" error can happen on any level of the code, or an "out of memory" or some other signal by the system or even CPU (think overflow). If sysutils is used, these are transformed to an exception, regardless of whether the code itself uses exceptions to report errors or not. The only way to know for sure there will not be an exception is not to use sysutils anywhere in your code or anyone elses code. Delphi introduced a coupling between sysutils and exceptions, and now we're stuck with that. Today, you'd need to write your RTL to get rid of them. 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 25, 2023, at 1:10 PM, Michael Van Canneyt via fpc-pascal > wrote: > > > In C you need to do something like this: > > Function MyFunction(out theresult : TResultType) : Integer; > > begin > Allocate A > ... > error condition 1: >Free A, exit (1); > ... > Allocate B > error condition 2: >Free A, Free B, exit(2) > > Allocate C > error condition 3: > Free A, Free B, free C, exit(3); > ... > // etc > // All went well, report 0 > theresult:=X; > Free A, Free B, free C exit(0); > end. Indeed this is an ideal example of why they were invented and it makes sense here. Honestly most of this mess could be cleaned up with smart pointers also and not upset control flow like exceptions do. I'm doing work with Swift right now and in particular a web framework that makes lots of database calls, all of which can fail so we use exceptions everywhere. The thing that Swift does well and FPC does not, is that it labels the functions as "throws" and calls have a "try" keyword before them so you know how the control flow is actually working. Because FPC doesn't do this any function could throw errors and thus those stack frames are inserted everywhere and add needless overhead when exceptions aren't used. It's also nice to not have hidden control flow potential on any function call Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
