[Gc] The GC_INIT() macro and binding libgc in D

Alex Rønne Petersen xtzgzorex at gmail.com
Sat May 12 08:44:11 PDT 2012


Hi Ivan,

Thanks for the clarification. That's indeed problematic...

I suppose the best I can do is use D's answer to macros (mixins) and
make people use that to initialize libgc. My only concern is that I
have to keep it in sync with the GC_INIT macro of libgc. Does this
macro change often?

Regards,
Alex

On Fri, May 11, 2012 at 8:13 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi Alex,
>
> 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).
>
> Regards.
>
> 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...
>>
>> Regards,
>> Alex



More information about the Gc mailing list