Just tested this against another test app I have (not mine, a demo app that's written in C) and it failed to link as it was looking for the C++ named-mangled versions of those externed functions. They should probably be declared with extern "C" around them so that they can be defined by C applications.
In hindsight I should have mentioned this before, however I'd always assumed HarfBuzz was a C library due to the way its API is designed, but the templates in the OT font code proves otherwise :) -Jamie. On 5 October 2015 at 19:58, Jamie Dale <[email protected]> wrote: > Just tested this and it worked fine. Thanks :) > > On 3 October 2015 at 13:20, Behdad Esfahbod <[email protected]> > wrote: > >> On 15-10-02 10:00 PM, Jamie Dale wrote: >> > That's similar to what I originally had, so I'm fine with something >> like that. >> > My only question is, what would hb_malloc_impl, hb_calloc_impl, >> > hb_realloc_impl, and hb_free_impl be defined to in your example? >> >> Define it to the name of your external function. I don't want to fix a >> name >> in HarfBuzz itself. Updated patch to add externs: >> >> diff --git a/src/hb-private.hh b/src/hb-private.hh >> index 07550cb..826e41a 100644 >> --- a/src/hb-private.hh >> +++ b/src/hb-private.hh >> @@ -54,6 +54,23 @@ >> #include <stdarg.h> >> >> >> +/* Compile-time custom allocator support. */ >> + >> +#if defined(hb_malloc_impl) \ >> + && defined(hb_calloc_impl) \ >> + && defined(hb_realloc_impl) \ >> + && defined(hb_free_impl) >> +extern void* hb_malloc_impl(size_t size); >> +extern void* hb_calloc_impl(size_t nmemb, size_t size); >> +extern void* hb_realloc_impl(void *, size_t size); >> +extern void hb_free_impl(void *ptr); >> +#define malloc hb_malloc_impl >> +#define calloc hb_calloc_impl >> +#define realloc hb_realloc_impl >> +#define free hb_free_impl >> +#endif >> + >> >> I'll go ahead and commit this. Let me know if it doesn't work. >> >> > I went with the extern function approach so I could inject my own >> allocator >> > functions into HarfBuzz at link time, rather than have to include any >> of our >> > code into HarfBuzz at compile time (since any local code changes we >> make have >> > to be re-applied against new versions). >> > >> > For your reference, this was my original implementation: >> > >> > /* Override the allocation functions when >> > * HAVE_EXTERNAL_ALLOCATOR is defined. */ >> > #ifdef HAVE_EXTERNAL_ALLOCATOR >> > extern void* _hb_malloc(size_t); >> > extern void* _hb_calloc(size_t, size_t); >> > extern void* _hb_realloc(void*, size_t); >> > extern void _hb_free(void*); >> > #define malloc _hb_malloc >> > #define calloc _hb_calloc >> > #define realloc _hb_realloc >> > #define free _hb_free >> > #endif >> > >> > Failure to define those functions in something that linked to HarfBuzz >> would >> > produce an unresolved external symbol error at link time. >> > >> > -Jamie. >> > >> > On 2 October 2015 at 08:08, Behdad Esfahbod <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Jamie, >> > >> > I'm opposed to runtime custom allocators, but am fine with >> something like what >> > you suggest. However, that has two down sides: >> > >> > 1. It touches a lot of callsites, >> > >> > 2. I have to add macros to make sure stock malloc etc are not >> used by >> > mistake. >> > >> > If doing 2., I might as well just define them to their custom >> behavior. Ie, >> > would this patch work for you: >> > >> > diff --git a/src/hb-private.hh b/src/hb-private.hh >> > index 07550cb..167c067 100644 >> > --- a/src/hb-private.hh >> > +++ b/src/hb-private.hh >> > @@ -54,6 +54,19 @@ >> > #include <stdarg.h> >> > >> > >> > +/* Compile-time custom allocator support. */ >> > + >> > +#if defined(hb_malloc_impl) \ >> > + && defined(hb_calloc_impl) \ >> > + && defined(hb_realloc_impl) \ >> > + && defined(hb_free_impl) >> > +#define malloc hb_malloc_impl >> > +#define calloc hb_calloc_impl >> > +#define realloc hb_realloc_impl >> > +#define free hb_free_impl >> > +#endif >> > + >> > + >> > /* Compiler attributes */ >> > >> > >> > >> > >> > On 15-09-30 03:49 PM, Jamie Dale wrote: >> > > Since there was no movement here I went ahead and hacked in our >> allocator by >> > > redefining malloc, calloc, realloc, and free to point to extern'd >> functions >> > > that I define in our application. This yielded some performance >> benefits for >> > > us, so I'm hoping that a more standard HarfBuzz solution might >> appear at >> > some >> > > point :) >> > > >> > > If you're not keen on the idea of allowing the allocator to be >> swapped >> > out at >> > > runtime, would you at least allow it to be extern'd at compile >> time? I'm not >> > > familiar with HarfBuzz coding standards, but I'd propose adding >> > something like >> > > a HAVE_EXTERNAL_ALLOCATOR define to control this, and then define >> your own >> > > allocator functions that you'd use in place of malloc, etc. >> > > >> > > Basically, something like this (I currently have this code in >> > hb-private.hh): >> > > >> > > /* Define our allocation functions. These may be provided by an >> > > * external source when HAVE_EXTERNAL_ALLOCATOR is defined. */ >> > > #ifdef HAVE_EXTERNAL_ALLOCATOR >> > > extern void* _hb_malloc(size_t); >> > > extern void* _hb_calloc(size_t, size_t); >> > > extern void* _hb_realloc(void*, size_t); >> > > extern void _hb_free(void*); >> > > #define hb_malloc _hb_malloc >> > > #define hb_calloc _hb_calloc >> > > #define hb_realloc _hb_realloc >> > > #define hb_free _hb_free >> > > #else >> > > #define hb_malloc malloc >> > > #define hb_calloc calloc >> > > #define hb_realloc realloc >> > > #define hb_free free >> > > #endif >> > > >> > > You'd then replace calls to malloc, calloc, realloc, and free >> from within >> > > HarfBuzz to use hb_malloc, hb_calloc, hb_realloc, and hb_free. >> > > >> > > This is basically the code I already have, except I >> > > redefined malloc, calloc, realloc, and free rather than create the >> > > hb_*variants, as I didn't want to change too much HarfBuzz code. >> > > >> > > Thoughts? >> > > >> > > On 31 August 2015 at 22:17, Jamie Dale < >> [email protected] <mailto:jamiedale88%[email protected]> >> > > <mailto:[email protected] <mailto: >> jamiedale88%[email protected]>>> >> > wrote: >> > > >> > > Hey, >> > > >> > > I'm not sure if this is correct place to post/discuss feature >> requests... >> > > hopefully it is. >> > > >> > > Our project makes use of a custom memory allocator, and we >> like to ensure >> > > that our third-party libraries are using this where possible, >> as our >> > > allocator can offer significantly better performance, and can >> also allow >> > > us better memory profiling and debugging support. >> > > >> > > A look through the HarfBuzz source code would suggest that it >> doesn't >> > > currently support custom memory allocators, and instead just >> directly >> > > calls the standard malloc/free/etc functions. I was wondering >> if you'd >> > > ever considered (or would consider) adding a way to override >> this behaviour? >> > > >> > > In my case, I'd just need a single global override to be set >> before my >> > > first call to any other HarfBuzz code... basically something >> like >> > > the FT_Memory struct from FreeType: >> > > >> http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Memory >> > > >> > > Thanks, >> > > Jamie. >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > HarfBuzz mailing list >> > > [email protected] <mailto: >> [email protected]> >> > > http://lists.freedesktop.org/mailman/listinfo/harfbuzz >> > > >> > >> > >> > >
_______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
