Re: [m-users.] MR_GC_free ?
Volker Wysk <[email protected]> Tue, 07 Nov 2023 20:17:06 +0100
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Am Mittwoch, dem 08.11.2023 um 05:53 +1100 schrieb Zoltan Somogyi: > On 2023-11-08 05:48 +11:00 AEDT, "Volker Wysk" <[email protected]> wrote: > > Hi. > > > > In the ODBC library, there's space allocated by MR_GC_NEW and explicitly > > freed with MR_GC_free. This confuses me. Shouldn't space allocated by > > MR_CG_NEW be deallocated by the garbage collector? If it is to be > > deallocated explicitly, shouldn't the space be allocated by MR_NEW and be > > deallocated by MR_free? > > Follow the definition of MR_GC_free in runtime/mercury_memory.h > to boehm_gc/include/gc.h. This leads to this (I couldn't understand the definition of this function): /* Explicitly deallocate an object. Dangerous if used incorrectly. */ /* Requires a pointer to the base of an object. */ /* An object should not be enabled for finalization (and it should not */ /* contain registered disappearing links of any kind) when it is */ /* explicitly deallocated. */ /* GC_free(0) is a no-op, as required by ANSI C for free. */ GC_API void GC_CALL GC_free(void *); So the gc explicitly frees the object and remembers that it has done so, so it won't be garbage collected later. Is it bad style to use MR_GC_NEW and MR_GC_free, since it should rather be done with MR_NEW/MR_free? (That's what those are there for, aren't they?) Volker _______________________________________________ users mailing list [email protected] https://lists.mercurylang.org/listinfo/users