Re: [Gc] The GC_INIT() macro and binding libgc in D
ivmai at mail.ru
Fri May 11 11:13:50 PDT 2012
In some rare cases (gnu-win32 DLL, AIX, Android .so) it is required to call GC_add_roots to register some roots based on addresses of _data/bss_start/end__ of application itself (not of that symbols of shared lib) and there is no easy way to get these values directly from the shared library code.
For other targets (or if you manually register all the roots), it is safe to call GC_init instead of GC_INIT.
(The rest of GC_INIT logic is just for the convenience of GC tuning).
Fri, 11 May 2012 19:42:23 +0200 Alex Ronne Petersen <xtzgzorex at gmail.com>:
> Hello folks,
> In making a binding for libgc in the D programming language, I've come
> across one particular macro in gc.h that worries me a lot: GC_INIT().
> As you may or may not know, D doesn't have macros, nor does it support
> directly including a C header file, so one has to write type and
> function declarations matching those of the C header file. This
> strategy actually works fine in most cases, except when the C code
> makes heavy use of macros.
> In libgc's case, GC_INIT() is very important for portable programs.
> The idea is apparently that it is defined to do some extra work needed
> for certain platforms that make initialization more painful than one
> would prefer. On other platforms, it just calls GC_init(). I'm
> honestly not sure why this additional logic isn't simply inside
> GC_init() instead of using macros. Having the logic in GC_init() would
> improve encapsulation, ease portability and binding to libgc, and also
> maintain some sort of binary compatibility across libgc versions.
> So my question is this: Why is GC_INIT() a macro at *all*? Why not
> just make GC_init() do the Right Thing and avoid relying on the
> preprocessor in the header file? It seems to me that everyone wins if
> GC_init() is made to do all the needed logic...
More information about the Gc