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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-18 15:39:48

From: "Jonathan Turkanis" <technews_at_[hidden]>
> 
> Compaq C++ for Tru64 seems to have found a problem with the iostreams library
> that none of the other compilers caught.
> 
> zlib and libbz2 allow the programmer to customize memory management by
> specifying a pair of function pointers for allocation and deallocation. I wanted
> to provide an adaption layer so that users could specify standard library
> compatible allocators instead. To do this, I defined a class template
> parameterized by an allocator and having two static member functions with the
> same signature as the allocation and deallocation functions, and then passed
> pointers to these static member functions to the zlib and libbz2 API.
> 
> 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.

> Is there some way to get around this?
> 
> If not, 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?

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.

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).

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

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;