[Gc] Re: The GC_INIT() macro and binding libgc in D
Alex Rønne Petersen
xtzgzorex at gmail.com
Fri May 11 11:11:18 PDT 2012
Relatedly, I just found this comment for GC_enable_incremental():
/* Safe to call before GC_INIT(). Includes a GC_init() call. */
But GC_INIT() != GC_init()?!
On Fri, May 11, 2012 at 7:42 PM, Alex Rønne Petersen
<xtzgzorex at gmail.com> wrote:
> 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