Re: [m-users.] Memory management confusion
Volker Wysk <[email protected]> Sun, 20 Apr 2025 00:58:08 +0200
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <[email protected]> |
Am Sonntag, dem 20.04.2025 um 04:05 +1000 schrieb Zoltan Somogyi: > > And one of "these routines" (see above) is MR_GC_NEW. In lines 1028/1029 > > of > > the ODBC extra library is this: > > > > // Doing manual deallocation of the statement object. > > Statement = MR_GC_NEW(MODBC_Statement); > > > > According to mercury_memory.h, memory allocated by MR_GC_NEW is GC- > > traced. > > This means that it is registered for later deallocation as well as > > searched > > for pointers to other registered memory blocks. It *does* get garbage > > collected. Why does the comment say "Doing manual deallocation"? Is this > > a > > documentation error? Or what could be meant by that comment? > > It seems to be a bad comment. That's what I wanted to know. > It was already present in the original commit > of that file from 1997, so I am pretty sure that the original author would > not > be able to remember why he wrote that. Can you remember why *you* wrote > a given line of code almost three decades ago? No, I can't. I wanted to know what *could* be meant by that comment. I was confused. And I still am somewhat confused, since the object *is* cleaned up manually. Actually, it would lead to a resource leak if it were freed by the garbage collector. The ODBC statement handle wouldn't be freed. It won't be deallocated by the garbage collector, but still... I'd say that the wrong memory allocation function(s) is/are used here. But I'll leave it at that and use a finalizer, in my version of the ODBC library. I need the garbage collector to deallocate the object, for what I have in mind: add support for prepared SQL statements. Cheers, Volker _______________________________________________ users mailing list [email protected] https://lists.mercurylang.org/listinfo/users