Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Pancho Newsgroups: comp.os.linux.misc Subject: Re: Joy of this, Joy of that Date: Sat, 23 Nov 2024 20:50:27 +0000 Organization: A noiseless patient Spider Lines: 63 Message-ID: References: <6iKdnTQOKNh6AqD6nZ2dnZfqn_idnZ2d@earthlink.com> <20241120081039.00006d2a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 23 Nov 2024 21:50:34 +0100 (CET) Injection-Info: dont-email.me; posting-host="0996b149b2c257ae77a172fc1c1f1afd"; logging-data="1967012"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0xShXq/4NDVaej1P1EsZSG5aw5ryD6WY=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:zJxKq00LL3dvj1/26aYkBu4M9LY= In-Reply-To: Content-Language: en-GB Bytes: 3896 On 11/23/24 19:16, Charlie Gibbs wrote: > On 2024-11-23, Pancho wrote: > >> On 11/23/24 07:09, Charlie Gibbs wrote: >> >>> On 2024-11-22, Lawrence D'Oliveiro wrote: >>> >>>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote: >>>> >>>>> All my programs contain a routine called quit_cleanup(); it takes a >>>>> single argument, which is either an error message or NULL. >>>>> It frees all allocated memory, closes any open files, etc. >>>> >>>> But all that is unnecessary if your program is terminating anyway. >>>> >>>> In *nix C code, a common convention is >>>> >>>> if («call failed») >>>> { >>>> perror(«doing what»); >>>> exit(«nonzero error code»); >>>> } /*if*/ >>>> >>>> >>> >>> Perhaps, but I'm a belt-and-suspenders guy - I like >>> to explicitly free everything come hell or high water. >> >> I can see that is nice, to understand what you have, >> but it sounds like hard work. > > It's not, actually. Think of it like a mechanic methodically > putting all his tools back where they belong in the box when > he's done, rather than leaving them lying around the shop. > It's more like carefully packing up a set of disposable tools into their disposable box, and then throwing the whole lot in the bin. >> However there are some resource you do need to explicitly >> free/release/close, some database locks for instance. > > Therefore, why go the bother of having to memorize which > resources you have to explicity free, and which ones you > don't? Get into the habit of freeing them all - you might > avoid tedious debugging sessions when you forget which is which. > It's hard for me to remember, because I'm so used to C# IDisposable "using" blocks, Java "try-with-resources", even try/catch/finally, etc. I see even C++ has "Resource Acquisition Is Initialization". My memory is that in practice you normally want to hold critical (unmanaged) resources open for as short at time as possible, and hence you tend to deal with disposal locally to allocation rather than having long lived stuff that needs to be cleaned on exit. But that is just a gut felling, I can't really remember enough to talk sensibly on the subject. I'm sure there are usecases where this doesn't in apply, but in general I think it does.