Re: [boost] [iostreams][tru64] can't pass static mem fn toAPI expecting extern "C"

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-07-18 16:06:49

Rob Stewart wrote:
> From: "Jonathan Turkanis"

>> Unfortunately, when compiled as C++, the zlib and libbz2 headers
>> declare the allocation and deallocation function pointer types as
>> extern "C", and Compaq (correctly, I think) refuses to let me assign
>> pointers to static member functions to variables whose type are
>> declared extern "C".
>
> The static member functions have C++ language linkage, not C
> language linkage, so Tru64 is correct.

>> ... what should I do?

>> 1. expose the C-language customization interface (yuck)
>> 2. remove the customization interface
>> 3. remove the customization interface only for platforms where it
>> doesn't work
>> 4. Use some more elaborate trick, such as supplying extern "C"
>> allocation functions which operate by delegating to pointers stored
>> in a table.
>
> The first question to address is whether the customization is
> needed.  zlib and libbz2 obviously provide the customization for
> a reason, but is that necessary in your library?

My eventual goal is to have all use of dynamically allocated memory customizable
by library users.

> Assuming the customization is needed, a mechanism such as 4 is
> appropriate.  You hide the extern "C" details in your library,
> but provide clients with a means to affect the allocation.

It's potentially pretty messy, though, especially w.r.t thread safety.

> If you design things such that use of the adaptation layer sets
> up and registers the extern "C" functions, but otherwise doesn't
> supply customization functions to zlib or libbz2, then 2 is a
> degenerate form of 4 (when no one uses the adaptation layer).

If I'm not going to allow users to customize memory allocation, there's no
reason to register any extern "C" functions, since zlib and libbz2 provide
reasonable defaults (presumably using malloc/free).

> Thus, 2 would be a good starting point, with 4 added later should
> a library client require it.

I guess this is what I'll do for now.

Thanks for your input.

Jonathan