memory management in C++ lib headers

[Anatoly Fayngelerin <fa...@gmail.com>]

Hi Everyone,

I am running into some issues integrating thrift into an existing build
process. The source of the problem lies in the fact that thrift headers
inline a large portion of the code. Specifically, TPipedTransport calls
malloc, realloc and free in the header. This becomes a problem in existing
builds when custom memory allocation is instrumented using linker
redirection (ld --wrap)

I would like to gauge the community reaction to a potential patch that would
move code that performs memory management into the ".cpp".  I would also be
interested in hearing if there are any reasons other than potential
performance gains for keeping this type of code in the headers.

Thanks,
Anatoly

Re: memory management in C++ lib headers

[David Reiss <dr...@fb.com>]

> I would like to gauge the community reaction to a potential patch that would
> move code that performs memory management into the ".cpp".
I think this would be fine for the most part.  TPipedTransport should be
fine.  That's actually not a very important
class.

> I would also be
> interested in hearing if there are any reasons other than potential
> performance gains for keeping this type of code in the headers.
There are a few template classes that do memory management (see
TBufferedTransports and TBinaryProtocol), so those probably can't be
moved.

We normally use LD_PRELOAD to replace malloc and friends.

--David

On 12/06/2010 01:52 PM, Anatoly Fayngelerin wrote:
> Hi Everyone,
> 
> I am running into some issues integrating thrift into an existing build
> process. The source of the problem lies in the fact that thrift headers
> inline a large portion of the code. Specifically, TPipedTransport calls
> malloc, realloc and free in the header. This becomes a problem in existing
> builds when custom memory allocation is instrumented using linker
> redirection (ld --wrap)
> 
> I would like to gauge the community reaction to a potential patch that would
> move code that performs memory management into the ".cpp".  I would also be
> interested in hearing if there are any reasons other than potential
> performance gains for keeping this type of code in the headers.
> 
> Thanks,
> Anatoly
>