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

Ivan Maidanski ivmai at mail.ru
Sat May 12 13:10:01 PDT 2012


Hi Alex,

Not often. But there has been a change in GC v7.3alpha since v7.2

Regards.

Sat, 12 May 2012 17:44:11 +0200 Alex Rønne Petersen <xtzgzorex at gmail.com>:
> 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
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list